Opublikowane
2010-05-16 21:25
The past few weeks have been just an amazing ride through the CiviCRM universe. We've had some excellent training sessions, an awesome CiviCon and then the sprints which produced a nice new book and some major improvements to our translation process. We've also been spending a lot of time thinking about what we want to accomplish with CiviCRM 4.0. So here are some of our thoughts, note that many of them are speculative and if something is really important to you or your org, consider making that part of YOUR OWN personal battleplan and contribute a design and code to make it happen.
My top 4 guidelines with regard to 4.0 are:
- No new features. 4.0 is a restructuring and refactoring of part of the code base. Our objective is to make the code base more solid and not focus on adding functionality to the application.
- Improved extensibility. We've heard the message loud and clear. We need to continue making it easier for developers to extend and customize CiviCRM. More documentation, More examples, More API's
- Improved testability. We need to continue increasing the test coverage of the code base. We are continuing with a strong push on this with 3.2 and have introduced Selenium into the mix. We hope to get the community involved in improving our test coverage in a big way
- Switch to a modern framework. The current CiviCRM code base is based on PEAR which is old and no longer maintained. We will upgrade the core libraries to a more modern object oriented framework, with a strong userbase / documentation / testability. To ease the transition we will stay with our current templating system but we will upgrade Smarty to v3.0.
- Change Logging. Keeping revision history of contacts and associated objects is a much needed feature. The ability to rollback to any prior version and/or undo the work of a single person over a period of time would make it powerful
- Workflow Engine. We think that for the first phase integration with the Rules module will give us some essential features. There is already a proof-of-concept module out there which demonstrates the feasibility of this approach
- Custom object support. Basically the ability to define and manipulate objects that do not extend a CiviCRM object. This will allow users the ability to add and manipulate tables in the schema in a more powerful and integrated manner. These objects can be linked to objects in CiviCRM via master-detail, many-to-many or lookup
- Customization of the UI via the UI Template customization is incredibly powerful and does rock :) However it would be great to have the ability to hide various form and page elements in the UI / reorder the elements graphically. i.e. manipulate the template layout via the UI. An additional feature would be to allow the same form to have "multiple" layouts. Thus someone can have a simple version and complex version of the Contact Edit Form.
- Integration with Google Docs / MS Office. Target Integration has released CiviSync which is a good first step towards synching with Outlook.
- Wordpress Integration Wordpress has been the top blogging platform and is rapidly expanding as a CMS. We should definitely consider offering a WP integration. The main issue will be support of the WP user base which might be on shared "cheap" hosting, something where CiviCRM is not well suited for :(
- iPhone/Android App. Would be really nice to see a mobile version of CiviCRM. Wonder if we can use Senbei as a starting point?
Comments
isnt Drupal a framework besides a CMS?
Drupal can be used as a framework but it's not as object oriented as CiviCRM, it doesn't have classes anywhere for example. That's probably one good reason not to choose it.
It might also be harder to get CiviCRM to run on top of Joomla, WordPress or as a standalone platform, although the drush integration could make all of these combinations easier to set up for anyone with a who's not scared of unix shells - though it seems silly to continue the standalone version if CiviCRM would be using Drupal as a framework.
Drupal would also be a very interesting option as it would attract many more Drupal developers towards CiviCRM. Several people have asked me why CiviCRM isn't simply a set of Features for Drupal and I think it would be great if it could actually be that some day.
Only joomla & drupal
All your arguments not to use drupal framework still are valid, of course.
X+
integrating with wordpress seems likely to happen in the next 6-18 months, IMO
lobo
Lobo - very exciting to read about your thoughts for 4.0.
Rather than installing CiviCRM within the target CMS, adopting a more modern framework in 4.0 might enable CiviCRM to always be installed standalone (I know that is currently being dumped) or within, say, Drupal, but then have modules/extensions within different CMS that use the relevant API to pull and push data from/to CiviCRM. This way the "core" team can focus on core functionality/services and the CMS specific teams (who may also be "core" CiviCRM developers but not in the "core" team) can focus on extensions to provide specific functionality within the target CMS.
While CiviCRM can run within Joomla! now, there are lots of limitations (eg Authentication/User sync) that make me wonder whether the current "dual CMS" development is delivering the best results. We often end up writing custom Joomla! extensions to communicate with a Drupal CiviCRM install, rather than running CiviCRM as a Joomla! extension anyway.
Hey Andrew:
We draw a lot of benefit from CiviCRM being a drupal module. Basically integration with Views2/Roles/User Registration is not possible via a "bridge" (if i'm understanding your suggestion right). Wordpress also has a plugin/hook architecture (i think), so that allows modules/plugins to talk to each other and exchange data nicely. I think Joomla 1.5/1.6 is starting to move towards this style
lobo
Four years ago when I looked at CMS options, I chose Joomla over Drupal for a variety of reasons (scary, manic logo!). So when I went looking for some kind of member directory solution, I discovered CiviCRM. I went on to deploy every Civi component except for CiviCase in Joomla, using Civi in that context for three years.
A year ago, before my wife's promotion and the start of our Manhattan adventure, I was the lead for oversight of the election process for the next bishop for the Episcopal Diocese of New York. I envisioned the search committee using CiviCRM to manage the information about potential candidates and interactions. We hired Brian Shaughnessy of Lighthouse Consulting and Design to build the site in order to keep all the roles clear. Brian and I had collaborated previously. WNY Bishop Search was built in Joomla with CiviCRM. Have a look, Brian built a great site! The whole idea hit a big snag though when it was time to use CiviCRM. The Search Committee members had varying degrees of computer literacy and were simply too daunted by Joomla's hard divide between front end and back end environment. The real power of Civi as a CRM is only available in Joomla in the back end. Most of Civi's power was never used for their process.
Since then I've built both a "proof of concept" Drupal/CiviCRM site for myself for use in episcopal elections and deployed Civi for the church where I'm serving as the interim priest.
Drupal is a FABULOUS framework! Wow! Customizations that would have been really hard in Joomla are easy. Although I had to build features like time based publishing of content, I could and I could make it work exactly like I wanted it to. It's designed to be extended with it's hook architecture. I'm now a complete convert! If I had to develop a site for a client and could choose - Joomla friends please forgive me! - I'd choose Drupal.
Attention is a form of capital. I agree with the Drupal advocates here and would say beginning with 4.0, focus on Drupal. If there is a way, as some comments here suggest, to somehow abstract a CiviCRM 4.0 built on Drupal and re-roll it for Joomla interaction or compatibility then form a Joomla support team from the Joomla coders in the CiviCRM to do that.
Focused attention on one platform from the core team will provide a stronger product and that platform should be Drupal 7!!
I would vote for a couple of priorities in a refactoring:
(1) Allow native, deep integration with Drupal. As Drupal moves from content management to "social publishing" the line between CMS/CRM will blur further so users will gain a lot from leveraging Drupal to do what they need. Views should be "natively" integrated (no editing of settings files), along with roles, workflows, navigation, D7 overlays, etc. Think through how Civi works with things like Ubercart from an architecture standpoint.
(2) Leverage Drupal's emerging architecture of features, contexts, Aegir, etc. to allow configurations of CiviCRM for different use cases ... CiviSchool, fundraising, case management, team fundraising, event management, conference management, etc. Why reinvent verticalization technology when it's mostly available in Drupal already?
(3) Natively support drush / Aegir as Civi deployment & management tools.
(4) Achieve Joomla & Wordpress integration (and other CMSs) via a bridge strategy.
If this means that Joomla users install Drupal to get Civi, so be it. Civi is already complex enough adding the Drupal dependency isn't going to make it so much more difficult for Joomla or Wordpress users to deal with.
(5) Native support for SaaS deployment models. Focus on enabling new deployment models for Civi beyond "install on a server." Move APIs to REST, support customization (interface), refactor permissions to support SaaS models.
Why reinvent verticalization technology when it's mostly available in Drupal already?
What a great way to phrase it. This is key, and is one of the core tenants of the DropCRM initiative, IMO.
http://www.DropCRM.org
Looking back at my post it looks like I'm advocating for Drupal as the framework which is not really my point -- I suspect Drupal might not be the best choice since it comes with an entire set of Drupalisms that are non standard to developers unfamiliar with Drupal.
Zend might be perfectly capable of meeting all those requirements. The only thing that might really tie one to Drupal as a framework would be the features, contexts, install profile stuff... that stuff is probably heavily dependent on the drupalisms in Drupal.
Not sure Drupal's verticalization technology is critical enough to drive us over to Drupal as a platform, but whatever the case, the architecture, regardless of platform, should be optimized for deep integration with Drupal.
"verticalization technology" what does this mean? i have no idea, so giving some solid examples would help me :)
Features module & Install Profiles.
http://drupal.org/project/features
Of course there are competing approaches as always, but Features seems to have the greatest commerical support. (Development Seed and Phase 2 Technology)
Ahhh... how I do love the jargon.
CiviCRM is a generalized CRM system that can support many different use cases. For example, someone might want to run their school (CiviSchool) on CiviCRM. Another might want to run their fundraising walk event on Civi (Personal campaign pages + events). Another might wat to run their club. Another might want to run the development (fundraising) department on Civi.
Each use case generally uses a subset of Civi features and during implementation, a unique "version" of Civi is created for that use case. Verticalization technology enables achieving the business goals of diverse Civi configurations without requireing the manual reconfiguration of Civi to fit the use case each time.
The simplest examples are enabling a Civi component & the navigation menu. Those technologies allow me to set up unique CiviSchool menus.
However, unlike Drupal, which has a lot of "helper" verticalization technology (features, contexts) I can't set up the perfect generalized CiviSchool menu and programatically configure the menu upon install (unless I modify the database directly).
Hope that is concrete enough,
Given how many Drupal CiviCRM modules there are already, using Drupal as its framework makes great sense. I strongly support this. The split in effort has, I think, held CiviCRM back, just as the work supporting standalone CiviCRM.
This understanding of Drupal is outdated. In present reality, Drupal uses classes in many places, primarily the new Database abstraction layer, the EntityControllers, and in Views module.
Also, there is nothing about Drupal that would make it harder to integrate with Joomla or Wordpress than the current collection of third-party libraries.
Change logging would be great - but isn't it a new feature?
A workflow manager building on Cases is needed.
There are lots of other UX improvements. For instance, inline editing, more flexibility to profiles, better export of multiple records, moving fields between custom groups, etc.
Might come before the 4.0 version.
Hi,
Have you started comparing the existing frameworks ?
On my list where QF/wizard/whatever pear module have been particularly not good:
1) shouldn't need a session with half a mb of stuff in it
2) Less hidden fields and other black magic, easier to add fields and manipulate the forms from the client
3) No more html blob spat by the framework, html is generated by smarty
4) If the framework was more documented than a single article written like 10 years ago, wouldn't hurt ;)
5) The Database layer abstraction "requires" you to write xml, then to add a BAO, then to write a form, then to write a page, and everytime to list more or less all the fields. Django is a good example of something much easier
On the new features:
1) a better and more consistent REST api, that could allow much easier integration with external systems or ajax stuff in the UI. That's not only about more apis, that's about better structured, using the proper verbs and uri naming convention....
2) A proper configuration system you can use from the shell. Configuring a EU friendly civi requests one hour of clicking around, and you always miss something. And that's a pain to do staging. If the api covers configuration, it might be easier to do that using drush for instance
I am personally not a fan at all of configuration on UI via the UI, as I do like to keep the templates in my SCM, modify them with my editor and the syntax highlighter and all the goodies that don't work that well in an html interface (that will be slower, harder to sync between the dev and production server, crash more...). In general, you don't code on an html editor, why would you want to do it for the template (because that's me not you that is going to do it isn't a good answer ;)?
Another way to look at the question is to ask, what is a framework? Really, it's a library and a set of conventions. What library functionality is missing from Drupal (when you include a few well established contrib modules)? What convention is antithetical to the goals of CiviCRM? What reason is there for using a third-party tool when one of your platforms already provides all the tools you need to build your application?
I gotta beat my old drum here, because I'd still rather work with the CiviCRM community on this, since I now consider a native Drupal CRM necessary & inevitable. It'd be really nice if the CiviCRM team could lead the way with it's extensive experience and insight into the business processes important to Non-profits and CRM users in general.
hopefully u'll validate and prove that this is doable with dropcrm. We'll monitor your project closely and see how that goes while we decide. good luck with drop
lobo
The DropCRM group is unlikely to release a fully-featured application before CiviCRM 4.0, unless I misjudge the expected CiviCRM timeline. At this time, we're contributing to other projects (like Profile2 and EntityAPI) which could be leveraged by CiviCRM.
If it were, there may not ever be a need for a DropCRM as a specific piece of software, and then the DropCRM group could be nothing more than a group of developers who collaborate broadly toward CRMish Features for Drupal.
+1 for new framework, +1 for that framework to be Drupal. CiviCRM seems to be continually re-inventing paradigms that are well established and mature in Drupal, but CiviCRM doesn't have the resources to get the quality as high as the Drupal equivalents.
Over the past year or two I've been often implementing CRMish projects in Drupal rather than CiviCRM because of the far more mature APIs and customizability.
I like it all so far. Regarding Wordpress, I think it's true that most Wordpress users have less robust hosting than CiviCRM needs, but most Drupal users have less robust hosting than CiviCRM needs too. All but one of my Drupal clients that added CiviCRM had to upgrade their hosting to some extent. Luckily these days most hosting companies offer upgrades to VPS plans that may be suitable.
Keep in mind that one of the reasons Civi requires so much server resources is that on every page load you have to bootstrap Drupal and Civi -- that's a whole lot of duplication of effort.
Does anybody know how many live sites are actually running civi on joomla as compared to drupal?
And who is the target audience for civicrm? Choose any link from the home page and within one or two clicks you are onto a page that is clearly for and by developers. So another stat I'd be interested in is how many civicrm developers are joomla developers.
If it's an active goal to try to grow to reach more joomla (or wordpress) developers, then that's not a bad goal, it's just not clear to me from the blog post if it is or not. There's a mention of wordpress, but it sounds more like an exploratory idea. If growth in the non-drupal developer audience is NOT a goal, then it seems that unless there is going to be more drupal integration in 4.0 all that's happening is the drupal developers are being held back.
Ubercart doesn't work with joomla. It seems to do ok.
Lastly, I'm not clear on the no new features part. I get the idea behind it, but I'm not sure how practical it is. New features is part of how I make money as a developer - if I can't work with it then I'm going to end up hacking core, or abandoning it and go off doing my own thing. I expect this will just be more of a guideline to help focus on the rewrite and not a strict rule?
hey dave:
thanx for the comment. In response to your questions:
1. Based on ping back stats (i.e. from folks who've successfully installed it and gone to the admin screen), we currently have 68% drupal and 28% joomla
2. yes, our goal is to actively reach developers across all CMS'es. We definitely need to figure out how to position so we get more developers from Joomla helping extend Civi-Joomla.
3. With regard to shopping carts, do we want to be like ubercart? or zen-cart? I think our goal has always been to be cms-agnostic
4. the "no new features" is more of a guideline, or more of a statement that this release is not "emphasizing a set of big new feature(s)" which pretty much all our releases have.
lobo
There is a lot of discussion of using Drupal as a framework to build CiviCRM upon. At the same time there is discussion about Wordpress and installing CiviCRM on less that idea hosting environments.
Let me make a suggestion.
I would strongly suggest that you make a concerted effort to build a complete and robust API (my preference is for a REST API... with proper use of Hypertext as the Engine of Application State... cf http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven).
Once you have a well built REST API with well implemented Caching, you can then build all the integration you want with other systems using that API; simply make sure that you implement the correct caching on your side.
For WordPress (or Joomla), you might want to have a complete interface into CiviCRM in the WP admin, but its more common integration point is going to be for the public side. There are many individual points of integration and each point can/should be its own extension. For example, the WP user profile could be integrated with CiviMember. An "Send this to a friend" feature integrated with CiviMail.
You might provide the ability to segment admin behaviour via the API so that the admins for my main WP site have access to CRM data regarding the various contact forms on the site, but the admin for my community site (say its Buddy Press) would have more access. Since I have regional affiliate sites, they have additional information regarding contacts in their geographic region.
The point is that once you have a robust API, you have a path for integrating with many different services. For example, one might want to integrate with Shopify.com or some other e-commerce package.
My $0.02
I have read through all the discussions on using Drupal as a framework or another. Interesting, but my (admittedly growing) knowledge is not deep enough for most of it. What I do miss though is what we want to achieve with a new framework? From the introduction I gather that PEAR is old-fashoined and not maintained. If that is the only reason to change, we would move to the framework that requires least work? Yet that is not the discussion. So what else are we trying to achieve with a move to a new framework? can someone explain so people with a little less technical background can also take part?
Am I correct in digesting that the big advantage of using Drupal as a framework is that we have a far larger community thati s likely to contribute to CiviCRM? And the risk is that people will automatically see civiCRM as a Drupal-thing and therefore not consider it when using Joomla, Wordpress or other CMS?
The big advantage is not only the larger community that is likely to directly contribute to CiviCRM, it's also the gigantic community that will be contributing to CiviCRM without even being aware of this fact - by add features to and fixing bugs in Drupal core and all the Drupal modules used within CiviCRM. And by working on drush/Aegir and all the modules that are used in many installations.
Installing CiviCRM on top of WordPress or Joomla could be a matter of fetching the latest drush and a CiviCRM/Drupal installer add-on for drush. It might even be possible to turn this into extensions for both Joomla and WordPress, that will let people add CiviCRM to their Joomla or WordPress install right from their browser. And with a "CiviCRM installer extension for WordPress" available there wouldn't really be a big risk in using Drupal as a framework.
Thanks Kasper, I get it!
Hey Erik:
that is indeed a good point that we need to consider. We need to upgrade to be on a framework that is maintained and updated (i.e. with security patches). We also need to minimize the amount of migration work, so a framework that has a similar pattern to what we currently use will be at a advantage. Ideally we'll also move some pieces of the code base (i.e. form layer, DB layer initially and then maybe template layer?). We definitely want to avoid rewriting the entire code base (that is not a goal of 4.0)
lobo
I would like to put in my 2 cents as a developer that supports/installs CiviCRM for both Joomla and Drupal. I think the reason there are more developers using Drupal is that a Drupal website needs a developer involved to have a decent website. With Joomla, a non-technical person can use Joomla and have a good website without serious effort. So there will probably always be more techie folks on the Drupal side. Yet we need to include more people in the CiviCRM community and allow as many organizations as possible to benefit from it. So if in the event Drupal is the new framework, there needs to be a VERY easy procedure to get CiviCRM+Drupal loaded, ie no harder than loading CiviCRM into Joomla today .
Plus there should be no loss of functionality regarding these keys areas:
1) seamless Single sign on to CMS + CiviCRM
2) the CMS menu creation wizards should be CiviCRM-aware. ( ie when I create a Joomla menu item, it is aware of the various CiviCRM objects. )
3) Provide some CMS modules/blocks/widgets that allow display of Civi info, such as upcoming events, PCP, etc.
4) If the CMS has ACL's, tie those to CiviCRM ACLs.
I started as a Drupal developer shortly before CiviCRM began to form (at least publicly), and years later I am still a Drupal developer. It's worked out well so I have not developed on other platforms. Therefore my perspective is limited when saying: if there is a vote, I would vote in favor of refactoring CiviCRM to use more of Drupal as a framework. However, I will continue to use CiviCRM into the foreseeable future if the project continues with non-Drupal base libraries. I can see advantages on both sides of the argument; I just like Drupal development well enough that if it was my project I would Drupalize it.
Learning the internals of CiviCRM has been about the slowest area of progress for me in growing into a better developer (vs. Drupal/jquery/ajax/third-party APIs and other things I've run into). What I perceive as a super-super-object oriented codebase is pretty opaque. Whereas my investments into learning various Drupal modules pays off with better overall understanding of the universal Drupal structures/conventions, none of that rubs off onto CiviCRM since it is so much its own codebase. I certainly would be more likely to contribute code improvements if the codebase was more like a traditional Drupal module.
Code aside, the team has really developed some strong user interfaces, concepts and tools in CiviCRM. I would not want any of that to go backward in order to get more Drupalish. IMO views/cck needs a LOT of work on top of it to really be considered a CRM solution. For real world users to have a chance at effectively using the CRM, the CRM admin UI needs to be really CRM-oriented and the related tools need to fit together. Those I think are the strengths of CiviCRM and the 3.x branch especially has brought a lot of polish and bridged some important functionality gaps.
OK, now I'm rambling but that's insomnia for you.
I think Drupal may not be the perfect choice as a new framework for CiviCRM. Drupal is fine tuned for CMS like operations and with the kind of bugs and issues CiviCRM has been seeing lately, it should look at a framework like CakePHP - in which everything can be filtered and manipulated in a centralized fashion.
I have been through a lot of CiviCRM code lately in an attempt to make it run on PostgreSQL. I can confidently say that it needs a framework with a lot of abstraction. An MVC framework would have been ideal. It would require a complete rewrite of CiviCRM though - which is not really an option looking at the comments and intentions above.
The present code is plagued with varying coding patterns, styles and arbitrary repetitions of otherwise re-usable code. These issues are the prime reasons for the kind of bugs versions 3.0 and 3.1 have faced.
Please read my post at http://forum.civicrm.org/index.php/topic,14103.0.html on PostgreSQL and why it should supported now, irrespective of the new underlying framework chosen.
hey druv:
good forum post on postgres, i'll respond there later today. would be great if you can elaborate on:
1. "plagued with varying coding patterns, styles and arbitrary repetitions of otherwise re-usable code." giving examples of all the places where u see this happening would be great (and we can clean it up also)
2. a bit more on your thinking behind: "a framework with a lot of abstraction". if you can make that a bit more concrete will help us rationalize what you mean :)
lobo
Many people are successfully running Drupal on PostgreSQL, so using Drupal as a framework would automatically bring PostgreSQL support. Plus, PostgreSQL support seems to have improved in Drupal 7, and I'm looking forward to seeing a performance benchmark of CiviCRM with MySQL vs PostgreSQL. In 2007 2bits found that MySQL was faster than PostgreSQL.
I cant agree more with you.
Cakephp as a framework is great.
Its mvc and ORM/Active pattern record is enough to beat the argument against any other framework.
I hardly wrote any query in last one year(reduces query writing by 90%)
To add on it has components for email,acl
behaviours to extend models,
helpers,layouts,elements to aid the view part of mvc.
More over drupal has no oops,no mvc.
It has survived only because of the large following.
I dont how people can manage procedural approach of programming.
Time for civicrm guys to move on to framework like cake which has great deal of abstraction and reduces repetitive work.
DRY(do not repeat yourself), the slogan of cakephp framework.
After all time is important for all of us.
I think everyone is making good points, and the discussion seems to be going from "what Framework" to "Drupal or not".
As someone that did a fair amount of CiviCRM work about a year and a half ago, I have to say I still have a bad taste in my mouth. Lobo and the developers are awesome and really responsive and as a project CiviCRM is really great, but my experiences trying to extend and use the API was very negative. I am mainly a Drupal developer, and admittedly I was a bit confused by Drupal at first, but soon was able to get running, but with CiviCRM, I was never able to feel like I understood how it all worked and how I could make it do what I needed it to, especially within Drupal itself.
Taking that into account and if the goal of CiviCRM really is to be cross-CMS, then I really think the project needs to change towards CiviCRM becoming a data service that provides interfaces for different CMS'. This can be accomplished by making CiviCRM just a database install with an API and higher level code to handle some logic on top. Then, separate interfaces can be made for different CMSs.
I think this is the only real way to make something cross-platform without going the route of something like Salesforce where the software is a standalone service and CMSs integrate into data.
If CiviCRM wants to integrate with a CMS (whether one or more) it needs to fully leverage the existing architecture that it is being put into, otherwise it just becomes a hack, and there will always be lots of points that are not fully sustainable or extendable. I think by trying to provide interface parts that work there way into multiple CMS platforms, it alienates almost all developers because you are not properly leveraging the CMS you want to integrate with.
Even if the framework chosen is Drupal (which I personally would love), then that would still need to be a data service to Joomla, Wordpress, or whatever with its own extension to integrate with the CMS and create an interface for. Only in this way will you be able to provide a platform that could leverage the existing community of developers for each CMS project.
My two cents. Thanks all for the great work on this project! (even if I havent been working with it for a while)
I follow the discussion about Drupal, Joomla, Wordpress etc. but to be honest non of these 3 CMS fits the needs of CiviCRM and the Organizations using it in Terms of Security or user rights Management or the way how to create in an easy way Templates and integrate them.
iPhone etc is already working in TYPO3 Sites.
Another great TYPO3 Feature is the way it provides Translations of content into other languages.
We for ourself decided to integrate CiviCRM into TYPO3. It delivers you not only a No. 1 CMS Solution but also a very secure CiviCRM Installation and Code Base beside the guaranteed 3 year Support for this integration!
If you are interested join and/or sponsor our effort!
Thanks a lot
Andi
I would be interested in hearing more about the security practices in the Typo3 community.
Full disclosure: I own a consulting firm that specializes in Drupal.
Raw numbers do not really explain how secure a platform is, and can be easily influenced by factors that play no role in an organization's overall security stance. In fact, a large number of security issues is often a sign of a healthy open source community.
The link you provided for security issues with Drupal is misleading. This is actually a link to a list of security announcements, which are disclosures from the Drupal security team about issues that have been identified and corrected. What is important to understand is that greater than 90% of the SAs on that list are in relation to Drupal core. The majority of these announcements are in relation to optional, contributed modules that would have no place in a CRM system in the first place.
But back to the original point: one essential element of good security practices in software engineering is peer review. Given that the Drupal community is so much larger than the Typo3 community, there are simply soo many more opportunities for people to review each other's code that, mathematically, this works out to an advantage for Drupal. The fact that there are more security annoucements about Drupal is a sign that more people are actually taking the time to review each other's code.
What specific processes contribute to a greater level of security in Typo3?
It's fine to suggest Typo3 integration, but I'm not sure your comparison of the security landscape is very accurate. You do realize that your link to security vulnerabilities includes 3rd party extensions -- not just the core software. I only saw one vulnerability on the Joomla list that affects core, and it was fixed in the latest revision. And there are plenty of very large organizations using Joomla and Drupal. So plug Typo3, by all means -- but paint a more accurate picture of the other CMS solutions.
I do hope this wasn't the reason the CiviCRM community chose not to build on drupal. Your assertions about Drupal are almost entirely false, the whitehouse & the bbc use drupal for example. Your use of the secunia security website shows a complete lack of understanding of how the drupal community works, and drupal of the four is the best design for large numbers of users.
Just wanted to let this list know people from Trellon have been devoting some resources to a Drupal based CRM system. This is not necessarily intended as a replacement for CiviCRM, but it could be.
In Copenhagen, we met with people from DropCRM and various NGOs who really need more robust CRM support. Some of this talk was in regards to online activism, there are some major differences in the expectations for an online activism system between Europe and North America. Long story short, there is room for another CRM solution out there.
Nothing to point anyone at yet, but we do expect to be releasing code long before Drupalcon Chicago in March. Happy to talk with anyone about their ideas for moving CiviCRM to Drupal.
I am one of the unfortunate users of the standalone version who has been unceremoniously thrown under the bus along with the other standalone users.
Please entertain the idea that there may be non-profit organizations out there who need a CRM like CiviCRM, but who do not have the resources to maintain an installation of a CMS like drupal or joomla AND a CRM. I happen to be a volunteer for one such organization... We need a CRM that functions as a CRM, that does not require security upgrades on a weekly/monthly basis, dependencies on 3rd party packages, major upgrades, a full-time developer to use and customize not only it but the CMS it depends on, and so on.
We already have a CMS for our forward facing site, we don't need another. The standalone version of CiviCRM mostly met our needs, with the exception of the dependence on openid as an authentication system.
What I would like to see is CiviCRM move towards becoming an actual CRM, instead of something dependent on a CMS.
Just my $0.02 ;)
Hello
Because i am reading at the moment some stuff about the future of php-frameworks, i remember this discussion. So you found an conclusion?
I really like the concept of Dependency Injection Pattern. so for that Symfony and flow3 looks really interesting for me.