D7 Port

This is a first patch to port privatemsg to D7.

A few, short comments:
- works, tests pass but will need additional work (for example, documentation)
- *only* converts privatemsg.module so far.
- the patch is big and might be rather hard to follow, I'm not going to explain everything here, feel free to ask if you have questions
- Done in this patch: All api/hook changes I could find, DBTNG (including our assembly_query function which is now just a simple wrapper function that does call the sql function and adds a tag), some theming stuff
- patch contains of 1200loc but much of that are easy changes...

Comment	File	Size	Author
#6	privatemsg.install-d7.patch	12.9 KB	NaheemSays
#6
	privatemsg_d7.patch	46.51 KB	Berdir

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

litwol CreditAttribution: litwol commented 11 September 2009 at 01:14

Version:	6.x-1.x-dev	» 7.x-1.x-dev
Status:	Needs review	» Fixed

As promiced. d7 development will be fast paced. Bear in mind that this freedom comes with responsibility.

Be careful to:
1) Not change important logic
2) Stick strictly to upgrading d6->d7 standards
3) no easter egg funnies (This one is punishable ;) )

Comment #2

NaheemSays CreditAttribution: NaheemSays commented 11 September 2009 at 02:59

Questions arise over the query builder - I see that it has been gutted, but do we still keep the way to access the queries or does D7 also have some other method.

Also, I see no changes to the privatemsg.install - is that expected? (I assume the install file also was supposed to be committed to the branch?)

Also, it has been committed, but I would have preferred if this went into privatemsg HEAD and that branch was renamed from 6.x-2-x-dev to 7.x-1.x-dev :/ I Don't like that we are leaving avenues for people to use old code.

Another question is over future development model - would patches etc need to be developed for both the 1.x branches in order to not let the base deviate too greatly, or should we not worry about this yet?

Comment #3

litwol CreditAttribution: litwol commented 11 September 2009 at 06:05

Only going to answer the last part: Once d6 hits stable (omg when is it going to happe?) Features will go to d7 only. I think following d7 core model is best idea. We can backport bug fixes or security fixes (what bugs? :-D). Until d6 hits stable we need to develop patches for both unfortunately. So lets get d6 wrapped up and finished already.

Comment #4

Berdir

German

Switzerland

CreditAttribution: Berdir commented 11 September 2009 at 13:07

Oh, that was fast...

Be careful to:
1) Not change important logic
2) Stick strictly to upgrading d6->d7 standards
3) no easter egg funnies (This one is punishable ;) )

I will try to stick to that. There are a few more or less minor logic changes as I tried to use D7 features when possible. Example: Instead of returning a string from the view page, I converted it to return a big array with #theme definitions and also removed our own alter hook in favor of hook_page_alter(). That gives other modules full control over the data of that page *before* it is rendered.

Questions arise over the query builder - I see that it has been gutted, but do we still keep the way to access the queries or does D7 also have some other method.

I was not so sure. We use several queries multiple times and so I kept the assembly function for now. we could also easily call our sql functions directly and add a tag inside them, but we have to do it every time manually. What I removed are the automatic count queries. The thing is, we have only a single instance where we actually need a complex count query together with a pager and I thought it is easier to create a separate count query manually.

Also, I see no changes to the privatemsg.install - is that expected? (I assume the install file also was supposed to be committed to the branch?)

There are no changes necessary, I think. what we can do is remove the drupal_install_schema() calls, because that should happen automatically now and we can also remove the 600x update functions as they won't work anyway. (direct d5 -> d7 upgrade is not possible)

Another question is over future development model - would patches etc need to be developed for both the 1.x branches in order to not let the base deviate too greatly, or should we not worry about this yet?

Hm, I am not sure. as litwol said, once 6.x-1.x is stable, we will not add new features to that but still, we should probably start a 6.x-2.x branch and backport *possible* things (for example, field integration will not be backportable)

Once d6 hits stable (omg when is it going to happe?)

Depends on you, patches to review are available :p

Comment #5

litwol CreditAttribution: litwol commented 11 September 2009 at 16:46

Depends on you, patches to review are available :p

Yeah :(. we need more reviewers. Between work, school and freelance i get almost no time at all to do any community things :(. We need to lure in more reviewers. who is up for the job?