Closed (fixed)
Project:
Domain
Version:
7.x-2.x-dev
Component:
Code
Priority:
Critical
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
18 Oct 2009 at 15:16 UTC
Updated:
3 Jan 2014 at 00:29 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
sunHeya! :) I see there is already code in HEAD... any status update or pointers to what needs to be done here?
Comment #2
agentrickardAside 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.
Comment #3
sunI 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.
Comment #4
agentrickardYou 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).
Comment #5
Ghostthinker commented@agentrickard - sounds realy cool. Subscribing for testing.
Comment #6
agentrickardI opened up the D7-dev tarball for download today. Non-functional, though the module .info files are correct.
Comment #7
agentrickardProper versioning for D7!
Comment #8
sunHm... 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.
Comment #9
agentrickardYea, 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.
Comment #10
sunNote 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.
Comment #11
agentrickardFine by me. But why am I seeing this now?
Comment #12
sunheh, 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.
Comment #13
agentrickardMy 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?
Comment #14
sunHm... 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.
Comment #15
agentrickardI 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?
Comment #16
sunDefinitely! :)
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.
Comment #17
agentrickardTrue. 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.
Comment #18
nonsieI 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).
Comment #19
agentrickardI 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!
Comment #20
sun@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).
Comment #21
agentrickardFYI: 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
Comment #22
nonsieSign 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.
Comment #23
agentrickardSure! 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.
Comment #24
agentrickardHaha. You already have CVS access to Domain Views :-p.
Comment #25
agentrickardI just committed a big patch that allows the core DA module to be installed/uninstalled properly on D7. First step!
Comment #26
agentrickardFor 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.
Comment #27
agentrickardMuch 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.
Comment #28
agentrickardhttp://drupal.org/node/749854
ALPHA 1
Comment #29
agentrickardHit list, in order of preference:
1)
Domain Source2)
Domain Conf3)
Domain Settings4)
Domain Alias5)
Domain Theme6)
Domain Nav7) 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.
Comment #30
agentrickardDomain 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.
Comment #31
agentrickardIf you're checking out from CVS, Domain Conf now works (mostly). It needs updating to account for new variables and changes in D7.
Comment #32
agentrickardDomain Conf is now done. Two notes:
-- Requires update.php
-- The new handling of secondary links is not accounted for in the block.
Comment #33
agentrickardDomain Alias ready for testing in alpha 5.
Comment #34
agentrickardDomain Theme, too!
Comment #35
agentrickardDomain Nav is in Alpha 7.
Comment #36
agentrickardDone.
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.
Comment #37
pebosi commentedMy patch fixes some call by ref warnings and finishes one db_update query.
please review
Comment #38
agentrickardNice. Did the existing update query not work? Passing an array to conditions should. The db_and() is not needed, since that's the default.
Comment #39
sunRight, the inner ->condition()s can just be unwrapped.
Can probably be fixed manually prior commit, so RTBC.
Powered by Dreditor.
Comment #40
pebosi commentedThe error with the query was:
Unknown column 'Array' in 'where clause'Updated my patch to remove db_and().
regards
Comment #41
agentrickardThanks! Committed!
Comment #42
agentrickard