What is the status of the D7 port?

From what I can see, looking at the CVS archive, there has been no work on the D7 branch in 6 months.

Are there any plans to move forward with this port?

Comments

aaronbauman’s picture

This is not at the top of my queue, but it will definitely happen.
The current D7 branch is in relatively decent condition, but probably not ready for prime time.

My motivation for further development on the D7 branch will likely be client-driven, and we are sticking with Drupal 6 for the time being.
I will make time to review and commit patches if there is traction behind a D7 release.

brianV’s picture

Given the long idle time that the D7 port has been sitting, does it make sense to re-do the port from the current version of the D6 branch?

aaronbauman’s picture

Yes, it makes sense to include some of the advances, bug fixes, and new features of the D6 branch.
But I don't whether it makes sense to start from scratch or to patch what is there.

The biggest difference between D6 and D7 is the notion of the generic "entity" -- a concept which D6 lacks.
Using an "entity" means that, in theory, an object can simply implement the D7's entity interface to become SalesForce compatible.

In other words, sf_entity replaces sf_node, sf_user, etc.
Further, this means that some of the bug fixes and new features of D6 are irrelevant to D7.

jpshayes’s picture

Hi, I would like to check in on the status of the D7 port for this module. I am about to start a site and all the functionality of the site is included in D7 core except the required functionality provided by this module.

I am a themer but have a good understanding of D6 API and also fairly schooled with the D7 API. How can I help?

brianV’s picture

@aaronbauman:

We are getting to a point in a project we are working on where we will soon be needing this module. Since the porting still needs to be done, we will likely be taking that on. Are there any suggestions you have in how to proceed?

My intention was to take your existing D7 port, and update any API calls that have changed in the intervening months. Following that, I intend to go through the issue queue from the date the D7 port was done to the current date and port all relevant patches. Hopefully, that *should* leave the module in a tenable position.

If others are interested in helping, perhaps they would consider tagging patches that need to be ported to the D7 release as 'needs D7 port' or something similar?

Aaron, would you consider taking me on as a co-maintainer through this process? Alternatively, I can do the work in github, and submit it back up to you if you would prefer to go that route.

aaronbauman’s picture

@brianV - added you as a maintainer

Your approach sounds good, in theory.
Once we get some folks using and testing D7 branch, hopefully we can get something out quickly.

using "needs D7 port" tag seems like a good tactic.
Would it also be helpful to change the status to "patch (needs ported)" and re-version accepted D6 patches?

Cross-referencing roadmap discussion: #1034498: Creating a beta release of the 6.x-2.x branch (and beyond)

brianV’s picture

> Would it also be helpful to change the status to "patch (needs ported)" and re-version accepted D6 patches?

That sounds like a very good plan! However, would you be able to take on this part? I am assuming that it would be a lot less time and effort for you given that you have much more familiar with the issues and D7-related changes than I have going into this.

EvanDonovan’s picture

@brianV, aaronbauman: This sounds like a great plan.

brianV: here are two bugs that were discovered recently from someone who I think was trying an upgrade from 6.x: #1033614: Missing "drupal_type" column in {salesforce_object_map} for 7.x, but still in primary key (needs schema update) & #1036044: Table salesforce_prematch already exists. Both are schema-related, it seems.

aaronbauman’s picture

OK, looking back on this, I'm not sure that this is going to be inefficient for 2 main reasons:
- some significant changes were not submitted as patches, e.g. #785278: Make fieldmaps exportable.
- there are an overwhelming number of issues to go through (100+)

The most significant divergence between D6 and D7 branches is the move from sf_user/sf_node to sf_entity.
After branching, salesforce_api and sf_prematch were not updated beyond D7 compatibility.

So, the approach I would suggest is
- run D6 through coder/deadwood, (let's call this D6-7)
- copy sf_entity.D7 into D6-7
- manually merge updates from sf_node.D6-7 and sf_user.D6-7 into sf_entity.D7 (I think this is the only step where reviewing issues for sf_node and sf_user might be useful)
- nuke sf_node and sf_user
- manually update any outstanding compatibility issues

brianV’s picture

aaronbauman:
It looks like Coder Upgrade isn't a viable path for this module. I tried running the 6.x-2.x-dev version of the module through it... and it deleted over half the code out of the module.

I am not sure why it chokes on it, but it looks like the port will have to be done manually.

Other than that, your plan above sounds reasonable if the volume of changes since the initial D7 port is too unwieldy to forward-port. I just wish I had seen this post before doing a bunch of coding style fixes to the 7.x-1.x branch. Oh well, c'est la vie.

brianV’s picture

Just a crosspost to an issue on how Coder Upgrade is choking on the Salesforce 2.x-dev tarball:

#1038632: Switch statements where cases are contained in curly brackets.

brianV’s picture

Coder is also choking on some of the bitwise logic:

#1038752: Parser does not handle nested bitwise operators

kevin.mcnamee@mailbox.org’s picture

We are also interested in using the D7 port. I have already done some basic testing of the API and entity modules. The prematch module has some schema issue that I have just reported.

However, what is of most interest is the sf_notifications module for synchronising from Salesforce to Drupal. When can we start testing? :)

EvanDonovan’s picture

More recent discussion (post-Drupalcon) has been happening at #1086910: [meta] 7.x Long-Term Roadmap. Perhaps this should be marked duplicate.

EvanDonovan’s picture

Status: Active » Closed (duplicate)

Marked as duplicate of #1086910: [meta] 7.x Long-Term Roadmap, since that has more recent activity.