We need to stabilize 6.x.2, decide what modules stay in the main release, and theb branch 6--2 and move to #d7cx.

#512770: Stable release tasks for 6.x.2.0
#557232: Split modules to subprojects

Comments

sun’s picture

Heya! :) I see there is already code in HEAD... any status update or pointers to what needs to be done here?

agentrickard’s picture

Aside from updating the .install files and the .info files, I think every element of the 6 > 7 upgrade checklist. I haven't touched any of the actual module code.

And we also need to sanity-check some of the code in light of changes like #654796: Identify fix bugs with checkbox element, when it gets in.

sun’s picture

I could probably help with many conversions, but I guess the most critical and most important change will be the port to the new node access API - which I'm unfortunately not familiar with.

Not sure about the status of coder_upgrade, but it's probably worth a try.

agentrickard’s picture

You can handle the node access stuff, which actually doesn't affect us much.

We can remove the hook_domaingrants() and hook_domainrecords() functions. Otherwise, it largely stays the same. We still return the same $grants arrays in both save/view cases.

The changes to the API are hook_node_access(), which we won't use, and hook_node_grants_alter() and hook_node_access_records_alter(), which replace the above hooks.

So removing those hook calls is all that should need to be done. Then domain_strict gets changed to use hook_node_grants_alter() instead of hook_domaingrants().

This is what happens when your code gets into core :-), since those _alter() hooks are stolen from DA (and I wrote the patch).

Ghostthinker’s picture

@agentrickard - sounds realy cool. Subscribing for testing.

agentrickard’s picture

I opened up the D7-dev tarball for download today. Non-functional, though the module .info files are correct.

agentrickard’s picture

Version: 6.x-2.x-dev » 7.x-2.x-dev

Proper versioning for D7!

sun’s picture

Hm... something is wrong with that version number - probably you adjusted it manually? I would highly recommend to use the regular version scheme, i.e. 7.x-2.x-dev -- otherwise, I guess that Update Status won't work correctly and probably similar problems regarding the issue queue. If you want, I can fix it for you.

agentrickard’s picture

Yea, I goofed when I created the release. I can't edit the version number, and killes had to change the title manually. if you can remove the major number, that would be great. We're just going to call this 7.x.0, I don't think keeping the 2 matters.

See the whole sordid tale here: #728366: D7 tagged snapshots from HEAD

By the time I was able to tag a release from HEAD, I simply misread the form.

sun’s picture

Note that a major version is required. I've fixed the release node now so that its definition is like any other HEAD release: http://drupal.org/node/728388 Since the module compatible with D7 will have the same features as 2.x for D6, and not the features of 1.x for D5, the major version should be 2.x. Let me know if you disagree or want this to be changed in any way.

agentrickard’s picture

StatusFileSize
new17.33 KB

Fine by me. But why am I seeing this now?

sun’s picture

heh, no idea -- however, I've also seen this before in other projects, and normally this should clean up itself after the packaging scripts ran again.

agentrickard’s picture

My biggest conceptual question going in: Do we get rid of the whole "the default domain is domain_id 0" issue, which is the legacy of a bad choice 3 years ago...

I know we have to either move 0 to 1 or remove the autoincrement on the {domain} table. The question is: How nasty will it be if we change 0 to 1? How many sites have a domain_id of 1 already, and how can we account for it?

sun’s picture

Hm... is it absolutely required to tackle this for a straight port? Due to the nightmare with D6, all projects in contrib are now following the paradigm: totally straight port first, rewrites in a new major version later. :)

If it's needed, then I'd say we should move 0 to a new id and use a "domain_default_domain" variable to assign and identify the default domain. This update needs to be atomic in a separate domain_update_700X function, so other modules can update their domain id mapping in corresponding module updates, before domain_update_700X+1 is executed.

agentrickard’s picture

I like it. Let's go with that plan.

-- 7.x.2.0 == Straight port
-- 7.x.3.0 == API changes / crap cleanup

But all new features would go into 7.x.3.

Make sense?

sun’s picture

Definitely! :)

Did you try coder_upgrade already? I didn't came around to try it yet, but I've heard that it "should work" and can do a lot automatically, vastly decreasing the amount of manual porting work required.

agentrickard’s picture

True. Haven't tried.

I should say, I don't like having to rev major APIs across Drupal versions, personally. I can see an 8.x.5.0 in the future, and I guess I just need to accept that.

nonsie’s picture

I like the idea of domain_default_domain variable instead of 0 or 1. However this also means that domain attributes should be available for all domains (such as marking default domain inactive for example).

agentrickard’s picture

I agree, though I don't think the default domain can ever be marked as 'inactive' as we need it as a fall-back.

ironically, I used 0 originally to try to prevent having to handle the domain_id of the primary domain and prevent its accidental removal. Design Fail!

sun’s picture

@agentrickard: this just crossed my mind... the porting/release tactic above could be tweaked to "more" by doing a straight port, ensuring that it works, release that as 7.x-2.0-alpha1, and afterwards, do whatever we want. Usually, there are lots of possibilities to improve the module's workflow/UI/whatever by leveraging new features of D7. Only larger API changes, I'd rather consider for a new major version branch only (stuff that invalidates documentation and breaks integration in other modules).

agentrickard’s picture

FYI: I had a change of heart and rolled Domain Theme back into HEAD, so that makes the D7 release package:

- Domain Access
- Domain Alias
- Domain Conf
- Domain Content
- Domain Nav
- Domain Settings
- Domain Source
- Domain Strict
- Domain Theme

The other modules I maintain, Domain CTools, Domain Prefix, Domain User, and Domain Views are stand-alone projects that could use maintainers. As could the proposed new Domain IDNA. See #732090: IDN Support for Domain Access

nonsie’s picture

Sign me up for Domain Views co-maintainership.

On a somewhat related note - are we going to do a code sprint/BOF at DCSF? Would be a good place to get some of the D7 stuff done.

agentrickard’s picture

Sure! I think we have to do a BoF, since the session didn't get picked up. And a code sprint might work, though I don't know when.

agentrickard’s picture

Haha. You already have CVS access to Domain Views :-p.

agentrickard’s picture

I just committed a big patch that allows the core DA module to be installed/uninstalled properly on D7. First step!

agentrickard’s picture

For sanity sake, I set the .info files to core version 6.x if the module has not been tested. Bad things happen to D7 when module install fails.

agentrickard’s picture

Much of the core functionality now works. Notes:

-- Changes hook_domainview() to match DBTNG.
-- Deprecates hook_domaingrants() and hook_domainrecords().
-- Bootstrap module registration now handled automatically.

agentrickard’s picture

Status: Active » Needs review
agentrickard’s picture

Priority: Critical » Normal

Hit list, in order of preference:

1) Domain Source
2) Domain Conf
3) Domain Settings
4) Domain Alias
5) Domain Theme
6) Domain Nav
7) Domain Content --> might be deprecated or rewritten

If anyone want to claim one to do the port, please feel free. Open an issue and tag it 'needs work' and take ownership.

agentrickard’s picture

Domain Source is done, except for Views and Domain Content integration.

See alpha2. Note that saving a node now issues a redirect to the source domain. This seems to be new (and potentially unwanted) behavior.

agentrickard’s picture

If you're checking out from CVS, Domain Conf now works (mostly). It needs updating to account for new variables and changes in D7.

agentrickard’s picture

Domain Conf is now done. Two notes:

-- Requires update.php
-- The new handling of secondary links is not accounted for in the block.

agentrickard’s picture

Priority: Normal » Critical

Domain Alias ready for testing in alpha 5.

agentrickard’s picture

Domain Theme, too!

agentrickard’s picture

Priority: Normal » Critical

Domain Nav is in Alpha 7.

agentrickard’s picture

Status: Needs review » Fixed

Done.

BETA 1 is now out.

There will be some API changes before 7.x.2.0 is released. See #763442: Drupal 7 API changes for notes.

Documentation updates should be filed here #763446: Drupal 7 documentation updates.

pebosi’s picture

Status: Fixed » Needs review
StatusFileSize
new2.42 KB

My patch fixes some call by ref warnings and finishes one db_update query.

please review

agentrickard’s picture

Nice. Did the existing update query not work? Passing an array to conditions should. The db_and() is not needed, since that's the default.

sun’s picture

Status: Needs review » Reviewed & tested by the community
+++ domain_theme/domain_theme.module	8 Apr 2010 18:47:19 -0000
@@ -160,12 +160,13 @@ function domain_theme_domainlinks($domai
+    ->condition(db_and()
+      ->condition('name', 'domain_theme')
+      ->condition('type', 'module')
+    )

Right, the inner ->condition()s can just be unwrapped.

Can probably be fixed manually prior commit, so RTBC.

Powered by Dreditor.

pebosi’s picture

Status: Reviewed & tested by the community » Needs review
StatusFileSize
new2.4 KB

The error with the query was: Unknown column 'Array' in 'where clause'

Updated my patch to remove db_and().

regards

agentrickard’s picture

Thanks! Committed!

agentrickard’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)
Issue tags: -D7CX

Automatically closed -- issue fixed for 2 weeks with no activity.