SELECT n.nid, n.type, da.gid
FROM node n, domain_access da
WHERE n.nid = da.nid
AND da.gid NOT IN (
SELECT d.domain_id
FROM domain d)
this select should not return any records, but it sometimes happen. (at least it happens when you modify the domain table manually. I am unsure if it happens with domain deletion)
So the problem is that there could be nodes which are not published to any domain, and there is no function to batch update the domain value for such nodes as they are not listed under any of the Domain Content lists..
Ok, I can simply update such nodes in db, but maybe I am not the only user experiencing this..
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | 474460-rebuild.patch | 709 bytes | agentrickard |
Comments
Comment #1
nonsieThe first question is - why would you modify domain table manually? If you are changing domain ids in the db then of course there will be side effects.
Comment #2
agentrickardBy design, all nodes are assigned to a domain, unless you are routing around the normal functionality.
Comment #3
pasquallethe same problem happens with the normal functionality also:
repro steps:
1. create two domains
2. assign a node to the second domain only
3. delete the second domain
bug: the node can not be found find with the Domain Content module
note: the original sql select I wrote in the issue will not return any rows (so that select is not good enough), but the issue still exist
Comment #4
agentrickardI would call that user error.
What solution do you expect?
Comment #5
agentrickardTry rebuliding the Node Access table after deleting a domain.
Admin > Content > Post settings.
Comment #6
pasquallehmm, the "rebuild permission" moved my node without domain to the default domain. I think I do not want that, when I have many domains and I just deleted one which I will not use any more..
Reassigning the nodes at domain deletion or automatically rebuild the node access is questionable.
I would definitely add more info to the domain deletion screen, something like:
You should reassign all nodes assigned to @domain_to_be_deleted to another domain before deletion.
Otherwise deleting the domain may result in nodes without domain and node access needs to be rebuilt (which will result the node without domain will be assigned to the default domain, and that could be a problem also).
I would probably add an option to see the list of bogus nodes, because I created some bogus nodes with my custom module also, using node_save(). So it happened many times for me.. Everyone should check this list first when something seems to be missing..
Comment #7
agentrickardI disagree. You are the first person in two years to complain about this, and rebuilding node access is the appropraite solution from a Drupal perspective, because DA may not be the only module.
Assigning to the default domain is perfectly reasonable. If your custom
node_savework caused errors, you need to eliminate those during testing.I do, however, like the idea of allowing users to select which domain to move nodes to when a domain is deleted.
Any chance of a patch? And if we assign orphaned nodes to another domain, we stlll need to rebuild node access.
Otherwise, the quick solution is to add node_access_needs_rebulld() to the domain deletion sequence. That could get committed immediately.
Better title, too.
Comment #8
agentrickardPatch. This is RTBC unless something better is written.
Also tempted to call this a bug, and move the "assign nodes" bit to a postponed feature request.
Comment #9
nonsieAgreed. We should try to push out a stable release before adding any more features.
Comment #10
pasqualleThe missing domain value can be easily fixed with opening a node and setting a domain value. So I did not bother to create an issue when it happened with incorrect node_save(). But when it happened with more than hundreds of nodes, then I started to investigate.
My original issue was caused by a wrong db backup and restore. The default domain 0 was not saved correctly, and new id in the domain table was created. New nodes were assigned to this new id, but we did not know that, we only saw that the domain access admin page does not work. We fixed the domain table, with setting back the id to 0.
So it was not really an issue of "messing with domain tables".. Similar issues with empty row backup are reported for the users table also, for the anonymous user row, so it does happen..
Although, I am fine with your solution, as you are right with "by design, all nodes are assigned to a domain".
test result:
after deleting the domain I am seeing the correct notification message
so RTBC
the patch contains trailing spaces, that should be fixed before commit..
Comment #11
agentrickardAwesome.
Did you get bitten by the NO_AUTO_VALUE_ON_ZERO issue for MySQL in strict mode? This happens with core, too.
@nonsie -- you care to clean up and commit this? A variation should go in the D5 branch, too.
Comment #12
nonsieThat's probably another issue that should go into documentation/handbook - restoring db from backup and making sure default domain doesn't end up with an id that's not 0. I've run into it a few times myself.
Comment #13
agentrickardThere is already an issue (with potential patch) for this tpe of problem #445386: Copying "users" table fails
Comment #14
agentrickardThis patch has been committed to HEAD and needs a backport, if there is an equivalent function (or we set a message) in the D5.
Let's file a new issue for the re-assignment stuff.
Comment #15
agentrickard