Author Topic: GSoC proposal:Drupal 8 integration (Read 1885 times)

torrance123 · February 27, 2014, 08:18:30 pm

Hi all,

I'm interested in submitting a proposal for Google's Summer of Code to help integrate CiviCRM into Drupal 8. I have a some ideas about what I'd like to prioritise, but I'd also like to hear what others would like to see as priorities or what are currently pain points that they'd like to have fixed.

As a start I'd like to

Map Civicrm objects (eg. contacts, groups, relationships, etc.) to Drupal entities. Eileen has already done a great deal of this for Drupal 7 with civicrm_entities module. This gives us a lot of free stuff in Drupal, especially a lot of Views configuration and Rules, but many many more modules will just work with civicrm entities.
Create some basic barebones cross-CMS objects in CiviCRM that allow us to perform very basic CRUD operations on CMS users, query for CMS users, check for username clashes, etc. — the kind of stuff that is handled in CRM/Utils/System. It would be nice to replace this with a shared CMSUser php interface and some dependency injection to replace conditionally calling concrete CMS objects throughout CiviCRM. Also, Drupal 8 has moved validation into the entity (and not the form) — this will bypass some of the yucky code currently in CRM/Utils/System/Drupal.php that has to mock form requests (yay!)
Full Views support
Some basic Rules integration and clear documentation about how to extend this.
Port CiviCRM contact ref module, which might be largely bypassed by simply using EntityReference field

This would leave civicrm_member_roles, civicrm_group_roles, civicrm_og_sync, and civicrm_engage modules — and I'd have to work out how to prioritize working on these modules based on community feedback.

That's a rough outline — I'd love to hear what others have as priorities regarding Drupal 8 integration.

ChrisChinchilla · February 27, 2014, 08:46:22 pm

Bypass smarty in favour of Twig or is that just crazy talk?

Great idea btw.

Eileen · February 27, 2014, 08:54:52 pm

Chris - can you start a new topic on that - & keep this one to Torrance's proposal

ChrisChinchilla · February 27, 2014, 08:58:06 pm

It is in reference, he asked for other thoughts and inputs, that was my thought.

Eileen · February 27, 2014, 09:00:14 pm

Sure - I guess it just seemed like a whole extra project.

ChrisChinchilla · February 27, 2014, 09:12:48 pm

Which is kind of what I thought, but threw it into the mix… The initial post is good to

totten · March 02, 2014, 07:31:16 pm

All of Torrance's suggestions seem like good ideas.

In terms of scoping, the thread has raised issues which have a few different scopes:

Items 1, 3, 4, and 5 mostly deal with the civicrm-drupal integration module. As I understand it, this means most of the work will be focused on a new 8.x branch in civicrm-drupal (plus a few Drupal specific classes in civicrm-core -- ie CRM_Utils_System_Drupal8).
Item 2 involves general cleanup of the Civi->CMS integration layer. It's likely to touch classes shared by some CMS's (like CRM_Utils_System_Base) as well as random hacky bits sprinkled around civicrm-core. I like the emphasis on PHP *interfaces* -- ie improving the interfaces and plugging any leaky abstractions. Random CMS-hacks and weak-interfaces will pose a challenge in doing any new CMS integrations (incl D8), so they're part of the critical-path for D8 integration.
Dependency injection (DI) is a great pattern which can complement interface-oriented software architecture, and I think we should introduce it to Civi, but I'm not sure why we would tie DI and D8 initiatives -- each can be done without the other. Maybe there are some examples/pseudocode of how these should tie-in?
Chris's comment on Smarty/Twig would (as I interpreted it) deal with the ~850 templates in civicrm-core. Agree that would be a whole extra project.

Eileen · March 03, 2014, 12:42:01 am

The drupal entity integration has 2 parts

1) appropriately declare CiviCRM entities to Drupal. I have done this to a limited extent in Drupal 7 - the most obvious gap being that the entity save action doesn't work
2) clean up CiviCRM entities to be more consistent & follow rules. One example of this is in hooks - EntityTag has a different hook signature to that of other post hooks whereas GroupContact entity does not always call the hook. Likewise there api related standardisation issues.

Many of these standardisation issues are technically simple but have backward compatibility issues - e.g the reason entity_tag & group_contact aren't 'normal' hooks is that they anticipate mass update via sql & we might need to consider changing our hook signature if we accept that mass-update is a legitimate approach.

So, I think the scope of this project needs to exclude doing all of that standardisation (but ideally sign post some of the the gaps). With the api we have a plan for dealing with moving compatibility (v4) but the move to CiviCRM 5.0 might be the time to review our hooks - in particular the pre & post. However, doing that is beyond what we could reasonably expect in this project.

In my entity efforts with 4.4 I limited the integrated entities because of inconsistencies. It may be that this is an appropriate way to limit the project scope - or alternatively Torrance can simply implement it as it would ideally work & the tidying up to really work that way can fall to those who come next.

Also, with the CMS integration clean up - we may need to harness some of the community to help out - is that acceptable within GSOC?

xavier · March 03, 2014, 01:05:43 am

I would like to see a better integration between civi contacts and drupal users. Right now, you only see that a contact is linked to a user, but not what role that user has or if he's active or not.

Would be very useful to handle spam accounts to search from civi all contacts that have a blocked account for instance.

X+

Chris Burgess · March 03, 2014, 12:29:01 pm

Quote from: xavier on March 03, 2014, 01:05:43 am

Right now, you only see that a contact is linked to a user, but not what role that user has or if he's active or not.

Would be very useful to handle spam accounts to search from civi all contacts that have a blocked account for instance.

We've built something along these lines on top of Eileen's CiviCRM Entity + Views - I'm not sure where it's at with the client but I'm hoping we'll have opportunity to publish it. Pete?

torrance123 · March 03, 2014, 01:11:46 pm

Quote from: totten on March 02, 2014, 07:31:16 pm

Dependency injection (DI) is a great pattern which can complement interface-oriented software architecture, and I think we should introduce it to Civi, but I'm not sure why we would tie DI and D8 initiatives -- each can be done without the other. Maybe there are some examples/pseudocode of how these should tie-in?

The reason I suggested DI here is that CiviCRM code shouldn't need to ask what sort of CMS it is currently interacting with, and then load the appropriate user object. DI would mean this would be declared once in config, and CiviCRM could simply ask for a generic CMS user object, handing off the decision of which concrete object to load to the DI container.

Not a deal breaker by any means — but certainly a nice-to-have.

CiviCRM Community Forums (archive)

News:

Author Topic: GSoC proposal:Drupal 8 integration (Read 1885 times)

torrance123

GSoC proposal:Drupal 8 integration

ChrisChinchilla

Re: GSoC proposal:Drupal 8 integration

Eileen

Re: GSoC proposal:Drupal 8 integration

ChrisChinchilla

Re: GSoC proposal:Drupal 8 integration

Eileen

Re: GSoC proposal:Drupal 8 integration

ChrisChinchilla

Re: GSoC proposal:Drupal 8 integration

totten

Re: GSoC proposal:Drupal 8 integration

Eileen

Re: GSoC proposal:Drupal 8 integration

xavier

Re: GSoC proposal:Drupal 8 integration

Chris Burgess

Re: GSoC proposal:Drupal 8 integration

torrance123

Re: GSoC proposal:Drupal 8 integration