Call to undefined function crm_get_groups()

Same error here.
Clean Drupal 5.7 install
CCK
CiviNode 5.x-1.2
One custom node defined
During adding of a 'CiviCRM Group' field to the custom node this error occurs.

The function crm_get_groups() is not defined in the code so I guess the function is a deprecated function.

I have checked for the presence of crm_get_groups() is latest CiviCRM 2.0 and 1.9. This function is indeed available in 1.9 and not in 2.0.

CiviNode And Civinode CCK needs to be upgraded to CiviCRM 2.0

I've the same problem. Installed CiviCRM 2.0 and it does not work properly with Civinode CCK.

Different (but probably related) problem confirmed with 5.7 and CiviCRM 2.0.1.

White screen of death on local system when selected on admin page and on dev server, white screen on attempted module install. Bad news.

I made a quick check on this and found the problem. civicrm/api/UFGroup.php is the file embedding the crm_get_groups() missing function. UFGroup.php is not (I guess it used to be) included unconditionally by civicrm, so the the related function is not found when called thru civinode.

So I just added one line to function civicrm_initialize () in modules/civicrm/drupal/civicrm.module :

FIND

// this does pretty much all of the civicrm initialization
$error = include_once( 'CRM/Core/Config.php' );

ADD
$error = include_once( 'api/UFGroup.php' );

Sorry for not posting a patch.

This simply make sure this civicrm api file is loaded and the related function available. Works for me on Drupal 5.7, civicrm 2.0, civinode 1.2 as this error does not show anymore. I did not test this thoroughly as I just wanted to testdrive civinode.

oops, another undefined function :
Fatal error: Call to undefined function crm_get_groups() in [...]/sites/all/modules/civinode/civinode_utils.inc on line 697

and this one does not seem to exist anymore in civicrm 2.0. I think it has been replaced by civicrm_groups_get() defined in /civicrm/api/v2/Group.php.
I guess I will test drive civinode when I have time to update it first.

I'm getting a similar error when simply clicking on the CiviNode settings while trying to set it up. I've got all the pre-reqs installed with latest versions and CiviCRM has been running fine for days and I have a few sample profiles created.

Fatal error: Call to undefined function crm_uf_get_profile_groups() in /home/public_html/energy.mazenti.com/public/modules/civinode/civinode_utils.inc on line 211

Here's a first attempt at the upgrade.

After a little more testing, here's an updated patch

This is not easy to patch.

I'm actually looking at the 2.x codebase, and I'm frankly pessimistic as to the amount of effort needed to fix this.

Here's a quick explanation. In many cases, there's a migration path for people that code to an API when it goes into a new version. For good or ill, the CiviCRM people did not do this; a large portion of the old API was simply dropped.

My sense is that most of CiviNode is going to need to get scrapped. Rewriting it from scratch is going to much easier than trying to fix it. The 2.x API is very simply a different API, and pretty much any code that was originally written for 1.x is completely busted.

For those of you who have been waiting for an update, here is my current take on it:

1) I'm going to assume that what people want is CCK support. So I am going to start with the CiviNode CCK module, and attempt to rewrite the back end of it from scratch.

2) I'll reimplement the autocomplete widgets based upon jquery; the dojo related code will get dropped. This should be transparent to users.

3) I'll try to do the same with the civinode_views code, using the 1.x Views API.

Pretty much the rest of the code I will simply scrap, since there is too much effort for too little return of any kind.

I'm not happy about this solution either, but then, I would not have done the 1.x to 2.x transition the way that the CRM people chose to do it. And I really hope that this is the last time that they maroon developers in the way that they marooned us on this one.

An additional comment on how I want to handle the 1.x ==> 2.x CRM transition.

I'm going to try very hard to make your CCK data just work in the new version. This will be done for Drupal 5.x to start with, since Views and CCK are *still* not completely finished for Drupal 6. Hopefully it will be easier to move to the new versions on the Drupal side than it was to move on the CiviCRM side.

@Torenware, Maybe I'm not using the full civinode capabilities, but this does fix the CCK/Views integration parts. I admit, that there's one more patch that was needed to pull the profile fields back but this patch basically does the job for me. I thought that was another bug in civinode, so I rolled it as another patch (that I'll submit in another soon-to-be-created issue).

New patch attached.

I've just posted a related, yet different, issue regarding upgrading to CiviCRM 2.x here: http://drupal.org/node/266456

so, yes we did mess up when we dropped support for the old api completely.

From our perspective, we got minimal feedback when we specifically asked the dev list for feedback / use cases of the api and how they would like to see it evolve. Check: http://www.nabble.com/Feedback-Needed-on-Future-API-Development-to128921... if you want to see the number and content of replies

However to some extent that is all spilt milk and we'll probably avoid making the same mistake again. I think it is quite important that developers and folks in the ecosystem take the time and energy to read blog posts / forums and respond to some of our questions. That way we have a better sense of whats happening and what needs to change.

lobo

With respect, Lobo. I've invested great amounts of time on the API, much of it on my own time. But understand why I might be upset here.

I've just found out that every job I ever did for every client I've ever done CiviCRM work for will have to be completely redone. The code won't port. Tested code will have to be retested. Try to imagine what the conversation between me and one of those clients will be like. Now try to imagine having that conversation multiple times with multiple clients. Because any developer that did serious 1.x customization will need to do exactly that, just as I will.

Back in 1.2 time or so, there were a number of developers who had previously done CiviCRM development that stopped doing it, largely because code they had previously developed had ceased to work. Thankfully, things settled down around 1.3 time, and most code written from that point of time was forward compatible. But a number of those developers did not come back. Those of us who stayed on bet on the platform. It's true that no one promised us that certain things wouldn't break at major releases. But if you look at other APIs, generally the changes are localized, and can be described in a couple of pages of notes (as an example: Drupal upgrade notes). That is not what the 1.x to 2.x transition was like: essentially any code that operates on contacts or groups needs to be rewritten in a new API. Since this covers most code that was every written for 1.x, this is not a small amount of code.

This isn't entirely spilled milk -- it's possible to "unmaroon" some of these APIs. A good general principle is to look at your sample code posted on the wiki, since those of us who wrote to that API took those pieces of code as a basis of "what would work". It would be good if a considerable subset of that code was made to work again.

I'm aware that this is very considerable work for the core team, but think of it this way: you will be saving almost every client of the developers who did custom 1.x work thousands (and in some cases) tens of thousands of dollars. This is a big deal, and it will affect in some cases whether some of these clients stay with the platform or not.

The problem is particularly acute in a case like CiviNode, since a lot of different people funded portions of it, and there is really no one I can go back to for a complete upgrade. I feel terrible about this, but really, what can I do? I'll salvage what I can, but I don't have the resources to invest the needed time to rewrite it from scratch.

I'd be willing to help with this backward port, as would, I suspect, a number of other shops who invested in the 1.x API would. And you guys should as well: the willingness of people to invest in the 2.x APIs going forward will depend on your developers believing that the 2.x is a "safe" thing to pitch to clients. You folks want to start on 3.x before too long. Look at it from the perspective of a client who needs custom work -- if you were in their position, would you think that was a good bet?

It would be really good if it were a great bet. But is it?

Rob:

I do understand and appreciate the time you've invested here. A few thoughts and comments:

1. Can we get more specific on what api's u r missing. If we get a list of whats missing and what is needed, we could potentially come up with some alternatives / fix in 2.1. in v1.9 (and 2.0) most API's were simple wrappers to BAO functions. So to a large extent the functionality is not lost.

2. Earlier in this thread, doug green has submitted a patch that fixes it for 2.0. Can u take a look at that patch

3. Would be great if developers of the ecosystem do respond when we ask for feedback. Makes life easier for everyone involved

4. Upgrading CiviCRM from Drupal 5 -> Drupal 6 took us a fair number of hours. (i'd speculate 100+ hours at least, but we also rewrote our menu system to isolate us from such changes in the future).

lobo

lobo

Additonal missing function:

PHP Fatal error: Call to undefined function crm_uf_get_profile_groups() in /***path***/modules/civinode/civinode_utils.inc on line 211

Shows up in httpd log after attempting to get URL /admin/settings/civinode (which results in the whitescreen of death only).

(Using Drupal-5.7 with CiviCRM 2.0.4 with Civinode 5.x-1.2 dated 17 Sep 2007)

(Update: Doug Green's patch in reply #12 takes care of this missing function as well, however warnings referring to sites/all/modules/civicrm/packages/dojo/dojo.js start showing up in the log... looks like it should be /civicrm/packages/dojo/dojo/dojo.js instead?!?)

subscribing/

Lobo, I'm very interested in your feedback on this new approach.

Try the attached patch, and the new civicrm20compat module.

Using a common module makes it easier for ALL civicrm dependent modules to do the upgrade. (See also #235904)

Doug:

thanx for taking the initiative to do this. this is quite cool and definitely the right way of doing stuff

lobo

I still get the error with the updated patch and compatibility module installed. Any one else experiencing this issue?

@vandit09, crm_uf_get_profile_groups() is in api/UFGroup.php which the civicrm20compat module should include. Can you make sure that the civicrm20compat module is enabled, and that you also applied the patch. Please make sure that you applied the patch by looking in the new civinode_utils.inc code for civicrm20_initialize(). Thanks!

Thx douggreen i have Also the Same but solved by patch you provide...now how i van get the contents from civi gorups

subscribe