Document: default domains for content types

This is actually a feature request, because it will require code.

By 'frameset' I think you mean 'fieldset' in the form. If not, please clarify.

This use case makes sense, it just was never requested to be configured by content type.

Currently, something similar is supported based on the domain a user is assigned to and the permissions that one has. See the information in section 4.2.2 'Content Editing Forms'. If a user is registered to community.example.com, you can force all of their posts to be made from this domain.

If you need to do this per content type, then we need to look at some changes via hook_form_alter(), either in the main module or in a submodule.

Take a look at domain_form_alter() then for ideas about how this might work.

I can see putting your logic into that function, or create a new module 'domain_nodetype' and execute hook_form_alter() there. The new module would fire after domain_form_alter() in Drupal's hook sequence, allowing you to edit the default behavior.

If we added this to the core, it would go into lines 1033-1149, adding (probably) a new IF check, which might require a new permission or setting. This code is relevant to what you want to do:

          // 2 == go to the user's assigned domain.
          case 2:
            $domain = domain_lookup($first_domain);
            if ($domain['domain_id'] != $_domain['domain_id']) {
              domain_goto($domain);
            }
            break;

I think it might be best to do this in a separate module, since the base use case works for most people and the admin settings are already very complex.

I have exactly the same need - to be able to assign content types to specific domains only...
but I don't know how to write a module to do it.

Similar to the original poster the content types need to be added to the appropriate domain and I don't want the users to have any choice or to get confused. Users in my case could have access to multiple domains - when they click create content the content type needs to be automatically posted to the domain it belongs to.

Otherwise I have to go around and check what is going on all the time and reassign the content - too hard :)

Please let me know if anyone gets to write a module for this please.

Thanks for all your hard work.

Do these rules apply to all users? To users by role? By permission?

This is probably a way for doing it manually....I am using 6x...but its the same for the case

From what i understand you want content type 'blogentry' created by all users to be published in

comunity.mysite.com .

For this ,under 'Create content' u can create a custom navigation link in menu,maybe 'Blogentry' pointing

to content form

at comunity.mysite.com/node/add/'blogentry'(so that the user is taken to

comunity.mysite.com's

create content-->content type form)and thus makin it possible for all ppts created to be shown only in

comunity.mysite.com.

This can also be done for product ie.,make a custom navigation link pointing to

comunity.mysite.com/node/add/'product'

Yes. In both Drupal 5 and 6 you can replace the standard menu items with custom menu items that are full paths to the domain that you want.

Just create a new menu item and disable the default one.

Still, a more elegant solution might be nice.

I would like this feature as well.

New features go into 6.x.2. Please patch against HEAD.

Hi,

I'd like to know if there was any new things here ?

I'm working with the 2.0-rc6 and I would like to set some default "domain access options" to each of my content types, and not have to edit my content, once created, to change the domain access options.

Is there a solution ?

(Thanks for all your work by the way !)

There are several possible solutions, but no one seems to be coding them at the moment.

I am busy with #443296: Tasks for stable release

Can give me a clue about those possible solutions? Maybe I can have a look in the code if I find some time.

Good luck with all the work !

See #3 above

+1
I hope this would work as "Default source domain" also, when "Rewrite all URLs to point to a single source" is enabled..

I would like this feature as well - my site is up and running, and this feature is would enable a community-subdomain, which currently no module does.

Bo :-)

will be trying this out. thank you for sharing.

@wildkatana

I really do not understand your approach. I am worried about the DELETE statement in hook_domainrecords(), which is not needed. The records in {domain_access} get updated based on what is returned by this hook already (see _domain_store_grants). You are also defaulting all content to 'all affiliates', which may not be desired and contradicts some other module features.

If you want to change the records for existing nodes, that should go into hook_enable() or an update hook.

I was also thinking about this yesterday, and if I wrote it, I would just use hook_menu_alter() to change the 'node/add' permissions callback to a domain-sensitive function. I would likely also put the configuration options on the Node type form, which is Drupal standard. Alternately, I would use hook_from_alter() to add the settings to the domain editing form ($form_id = domain_form).

the module as described in comment #3

No, this module does not change that logic. Source domain per content type is not implemented in the attached module..
I was thinking about the same in comment #15.. Default domains can be more, but source domain is only one, so it is a little bit different issue.

The only option for now is to redirect to one selected domain (that is already part of Domain Access module).

$GLOBALS['_domain']. Though we probably should make a function for that.

You might just be able to use domain_goto(), which does much of this for you. I don't know the structure of $defaultDomains. domain_goto() expects a $domain array as an argument. So at least you can do:

      if (!in_array($domain['domain_id'], $defaultDomains)) {
        $domain = domain_lookup($defaultDomains[0]);
        domain_goto($domain);
      }

You should be able to check the $a3 and $a4 value to see that you are on a Page instead of a Teaser view, and then only redirect on a page view.

If you are using separate url_alias tables for domains, then you may want to do a goto node/NID, and Drupal will fix the path for you, I think.

There is also a hook_domainpath() for cases like this, but use it sparingly. If you used Domain Prefix to handle the {url_alias} table, this should be handled for you if you call url("node/$node->nid") in your code. Then run drupal_goto() on the result.

With reference to #25 and #26, see #504528: Add domain_get_domain()

The likely problem is node_view() in the theme files, which may be inconsistently setting $a3 and $a4.

I have updated the module in comment #22. The default domain settings were not applied when the node is created automatically (not through the node edit page).

the module can be downloaded from here: [removed]

still no redirection is implemented in this module.

---
edit: download link removed

FYI: Pasqualle's solution has been released as a separate module.
Please take a look at it: http://drupal.org/project/domain_nodetype
Feedbacks are welcome.

Hooray!

In D7, btw, this becomes much easier.

Awesome! Thanks zserno & Pasqualle.

#37:
could not find this functionality in D7 yet.
agentrickard, if there is still no functionality for this planned, I will write a module for D7 (similiar like domain_nodetype). Please answer which plans you have on this. Thanks :)

I have no plans. Though there might be an open feature request.

I would accept a patch as well.

The "needs work" status only applies to patches.

All right thanks! I will work on a patch then and post it here.

A first try.

The idea of this patch is to add a 'Node defaults' settings page in /admin/structure/domain/bundles.

I moved the 'create new node' behaviour and 'publish to all domains' settings from the domain_configure_form to the Node defaults page.

New features
- set up if the currently active domain is assigned to your node automatically
- set up to which domains the node is published on default.

This should fit the feature request.

@agentrickard: I developed this on 7.x-3.3 first, commited to 7.x-3.x-dev then, hope this works :/

attached patch is old.

oops, forgot a little fix in the new function. please test this attached one.
old patch, not recommended.

Proper status.

This also needs tests, though domain_node_get_default_affiliates() should make that easy,

Yes, could you tell me how to perform the tests? I'm new in providing patches.

Tested with Feeds importers, works correct with attached patch.

*sigh* Should have cleaned up the code earlier.. here it goes again with cleaner code in domain_node_get_default_affiliates() and my changes in domain_node_access_records().
Ready for testing now :-)

The patch needs to be cleaned up for coding standards. I'm seeing a lot of inconsistent indentation.

sorry about that :(
fixed:
- replaced tabs with whitespace
- corrected function calls
- corrected code structures

Coder module now reports no warnings regarding this patch. If I missed something important regarding coding standards, please tell me. I appreciate a lot that you take the time for this, many thanks :)

Just little things. This comment, for instance, should be a complete sentence, with proper capitalization.

// get the default affiliates, use currently active domain as fallback

Next try :)
fixed comments

please excuse my mistakes. I had forgotten to add the new persistent variables to variable_del in hook_uninstall. Now there they are. Tested the uninstall process, working fine on my dev environment.
In future I'll be more careful.

This UI needs a lot of love. I'm testing with a dozen domains, and it's pretty hard to use. That said, I'm not sure how it might be improved.

I suspect that the old show/hide behavior for the default radios needs to go away as well. I think these new settings replace the old ones.

I thought a lot about the UI. The node defaults page should stay, because you should be able to configure everything regarding the Domain Access module on admin/structure/domain. It's difficult to find an agreement for easy use between number of domains and number of bundles.

I think a good solution would be to additionally provide configuration of the domain access settings at the view of the bundle, accessable like in the attached screenshot. On the field edit page you have the domain field rendered like in the node_edit_form, and there you can set up the default values.

Unfortunately I don’t know if my proposed solution is even possible, because node->domain is a pseudo-field, and I could not find the method to add a edit page for pseudo-fields.
I can investigate further, if you think this solution would be nice.

The D6 module Domain node type already does it this way, but the configuration appears on the node settings page like in the screenshot. So this definetly would work, but I'm not sure if you like it.

I suspect that the old show/hide behavior for the default radios needs to go away as well. I think these new settings replace the old ones.

Please confirm that I understand it right: The radio buttons for "Show on all affiliate sites" and "Only show on selected sites" should be removed, instead "Send to all affiliates" are checked by default when the user makes no changes at this, right?

I think the Domain Node Type pattern is what we need to support. We can replicate those settings in Domain Conf if we choose to. Or we can build something that looks like the User Defaults tab, using a table for easier scanning.

Yes, I think the radio buttons need to be removed in favor of the new settings, which are more granular.

User Defaults' table is good. I also thought about this, but switched to the current (fast) solution then. I was worried about when you have about 50 bundles, the table may explode so we'd have to create multiple tables. Uhm.. but why not, I also think it's far better than the current one, plus User defaults and Node defaults look similiar to each other then.

Okay so I will write a new patch, currently planned with following changes:

- Remove the radio buttons
- Change the domain_node_[node_type] variables to arrays, containing:

['all'] -> 0 || 1
[domain1_machinename] -> 0 || 1
[domain2_machinename] -> 0 || 1
...

so that we can get the default info whether the node is published to all domains and to which domains the node will be published / belongs to.

- Build form similar to User defaults, creating new table for every 15 (I think that's ok) node types
- Provide specific domain access settings on the node type configuration pages. The settings will appear straight in the vertical tabs just like in D6 node_type module.

I think this would be the proper solution. Do you agree?

Edit: Updated regarding #60. Will provide the patch soon!

In the 7.x.3 branch, I suspect the keys for those domain settings need to be the machine_names, for exportability.

Otherwise, this looks good.

Sorry for the delay, I was busy this week. New suggestion see attachement.

This patch needs to be tested. Unfortunately, I'm not familiar with drupal's testing methods.
If someone is good in that, please feel free to adapt this patch for the automated patch testing.

Furthermore, please make sure that the radio replacements are set correctly. I've tried very hard to fit everybody's needs in that. Since there shouldn't be a use for domain_behavior anymore, I marked this in domain_uninstall(). Sometimes, only DOMAIN_INSTALL_RULE is left for setting things up. Of course these changes can be easily seen in this patch.

I need to add an update method.

Attached patch is not recomended. Try #65 instead. Please excuse my mistakes.

Here it is, ready for testing.

What's the next step? I can't find here on drupal.org where to put this patch for testing. I think automated testing is disabled here.

It is, because you have to edit settings.php for DA to work. The tests have to be run on a machine that can handle DA.

I've been out on vacation.

Ok, so I just have to wait until it is tested on your machine, right?
I wish you a nice remaining holiday!

Great work you guys. I have applied the patch manually and it works great and it is exactly what i was looking for, so far so good.

i think it would be wonderful if the patch can be added into the module after further testing.

Once again Great work

There are some cleanups I'd like to see. The most glaring issue right now is the function domain_settings_node_access(), which has to be changed because it is a core hook for the Domain Settings module.

The help text needs a good editing.

This function name was stupid, excuse me. I have to mention that I'm not good in english, and don't have much freetime anymore (my exams are coming soon). I'd like to ask for someone who has more (say a lot) experiences in developing for drupal to create a good patch for this. I don't know if this one would ever be ready for a commit. Anyway, fixed the glaring issue and tried it with another helping text.

I think this just needs a cleanup. There are some inconsistencies in the text, but the functionality seems to work fine.

I am not entirely clear on the purpose of "Editor's current domain" setting, however.

I changed the setting's text to "Author's currently active domain", which should be easier to understand. This setting should stay because the feature already existed before (This was in your default domain behaviour). I (and many others for sure) need this setting.

I've checked my comments and variable names, I don't know further improvement anymore. As said before, I'd ask for someone who's better in that.

I just need to clean this up; but I'm really busy :-(.

Thanks!

Hi

Attached is the patched domain module for default domains with the patch from comment #65 patch 1.

Just download and intall the domain module as required in the documentation and it will come with the default domain settings

Hope you like it

docans, please read and follow instructions from Making an issue report. We don't need various versions of modified modules here. Please make the purpose of drupal issues and patches clear to you. Thanks.

#74 is the current one to be tested, which will be cleaned up and will be committed to 7.x-3.x.

See also http://drupal.org/patch/create

Sorry, if my contribution was not needed, just wanted to help. Is there a way i can delete it. Sorry for any inconvenience.

No worries.

Hi

I will like to know if the default domains for content types feature has been included in the new release

Thank you

docans, please do not change the issue's title. This is not a title of your comment, it's the title of the issue you are changing. If not yet done, please read links given in #77 and #78.

As seen in the release notes, this feature is not yet included.

This patch needs to be tested and reviewed before it can be commited to 7.x-3.x branch. And as written in #75, the patch code has to be cleaned up first.

And I was thinking about this one today. I had forgotten to check that we are using machine_names as keys. We are, but I don't understand the need for a prefix. Machine names are already unique, and this is a domain-specific setting.

$options['domain_' . $value['machine_name']]

Using the prefix here is just potential cruft, because we have to handle conversions within domain_get_node_defaults()

I used the prefix to prevent the case when someone calls his/her types with machine name 'all' or 'active'. And I wanted to have 'all' and 'active' setting in one variable per type.

I also thought about storing a variable for 'all' which whould contain the setting for every node type, same thing for 'active'. Then the prefix wouldn't be neccessary, but I'd have to call variable_get() three times: For 'all', 'active', and the node type. Then I'd have to build settings array by merging the needed values with the stored settings variable for the node type. For me the prefix was a more comfortable compromise, and I think the Saviours are different for the way of implementation.

Someone else may feel free to do a more elegant implementation. Currently I am busy with study, exams and project work :/

Thanks for the explanation. I think the solution is to change the other two to "domain_all" and "domain_active".

What about using uppercase DOMAIN_ALL and DOMAIN_ACTIVE? Might be a little bit confusing since those are no constants but machine names must not have uppercase letters -> no propability of conflicts.

To maxelli :
I was just asking a question and you have replied, what problem do you have with the title of my comment

i will like to know if i can apply the patch in #76 to domain 7.4 and it will work as expected or i should wait until the feature is added to the next release

Thanks

docans,

either you don't understand what I told you in comment #82 and before, or you just don't read carefully.
Once again (last words on this):
The title you've changed here is the issue's title. You cannot set a title for your comment here.
Feel free to ask and comment, but just leave the title here unchanged.

Answer to #88: If it's a productive live site, don't apply the patch and wait until the feature is included. You may try this patch on a test environment and report us here if there are problems coming from this patch.

To maxelli

Thanks for the reply, i did not know that i am not supposed to use the issue title for my comment title.

Secondly about #88 , the site i am working on is not yet a productive site but it will be soon. It is already online on one of my servers.

If you dont mind can i go ahead to update the domain to domain 7.4, apply the patch and get back to you on the results and i can give you the link to the website if you are intrested

What do you think

LOL

Next try, no domain_ prefix anymore and written for latest dev.

To Maxelli

I have applied the patch to the latest dev dated (2012-Jun-01) and applied it to my website. So far so good, no error.

The only issue is that i had to reconfigure my menus and content type back to their default domain after i updated to the dev with patch. Looks like the default settings were not saved in the database or ported into the update. But its all good. Just a few minutes of re-editing.

Good job done

Thanks

I want to have nodes 'Send to all affiliates' and set 'souce domain'.

But both are not set.

• After apply this patch, nodes seems will not be able to publish to current domain(without setting a specific domain) while not user active domain.
• Can we make the default setting the same with 'DOMAIN ACCESS OPTIONS'?

I think this would make sense, as users can register on any domain, while they uaually want to publish node to current domain.

rogical, which version of Domain Access and which version of the patch are you using? Did you run update.php immediately after applying the patch with Git? Do your users have a role which contains the right to publish nodes to all domains?
Default Domain Source options are not handled here, only default publishing options. Please open a new issue if you want a feature like this, thanks.

•After apply this patch, nodes seems will not be able to publish to current domain(without setting a specific domain) while not user active domain.
•Can we make the default setting the same with 'DOMAIN ACCESS OPTIONS'?

Unfortunately I don't understand what you mean.

I Have recently discovered that when a new user create a new account. The account is set to active but it is not assigned to any role automatically.

I have created a role called [ Basic Member ] but can find the options to set newly registered user to be assigned to the [ Basic Member ] role. So New users get [ Access Denied] any time they try to access the node/add page to add a content.

When i check their people link at (/admin/people) it show the new user but the status is empty meaning it has not been assigned to any role, not even as an [authenticated user]

Secondly i can no longer locate the set default role for new registered user

Please help me locate this option and make the necessary correction

Thanks

I'm getting tired.

Attached are some screen shot to issue #98

Note on the People list.jpg
1. The " Mark " user is a newly created user created my the user himself on the user registration page
2. The " Dela " user was created by administrator so the user was assigned to the [Basic member] by the administrator

The problem as stated above is to automatically assign users who create account using the site user registration page to be automatically assigned to the [Basic Member]

Thank you

To maxelli

Please dont get tired. We will all try and figure it out, that is why we are a community. All the best.

Changing title back.
@docans. Please don't change title. If you have another question / problem. Pleas open an new issuu.

I'll test and review patch today.

Patch basicly works.
1 warning:
domain.module:
argument of array_flip is not an array
line 3986 added extra if does the trick:

if (is_array(domain_default_node_access_settings($type))) {
    $settings = array_flip(domain_default_node_access_settings($type));
}

Otherwise looks good according to me. Also some trailing whitespaces

When did it occure? I assume you run update.php immediately after applying the patch? Before you added extra code, did it occure regurarly or once? Thanks for your feedback!

My mistake. I reapplied. And run update.php.
No error's found.

Never mind, thanks for testing again.

Reviewed and cleaned up the following:

• Content type editing page mismatched the 'DOMAIN_ALL' value from the Domain settings page.
• Turned DOMAIN_ALL and DOMAIN_ACTIVE into defined constants for clarity.
• Menu order was incorrect. Fixed.

Can likely commit, then add tests.

Good news. Looking forward for the new feature and I want to say thanks to agentrickard for your patience. I really appreciate your help, I have learned a lot. I hope in future I also can provide some useful patches for you to make this awesome module even more awesome.

I think you've been more patient, waiting for me to review things.

Next step will be updating the documentation. I'm working on some tests.

Hi, everyone!
I'd like to know how soon will we be able to get this feature in the module itself? I mean, I do not want to "hack" the module files now with the patch, because the necessary feature will be removed when updating... But I need it so much!

Would really appreciate a release for of this feature as soon as possible too.

Then please write a test.

Committed, with tests. Nice work!

So, who's up for documentation on this one?

Sorry, I've been absent for a while, at the moment I'm on vacation.

I'd like to write a documentation for you, but I don't know how to properly give you the needed data. Do you have have a link for me with a tutorial how to correctly write documentaions for Drupal modules? I could write a chapter for the README if you need this.

Offtopic: I'm going to travel to California from August, 21st until September, 11th. My girlfriend an me will drive from San Francisco, down to San Diego, then to Las Vegas and back to SF. May someone is on the way, who's an experienced Drupal developer, and/or works at a company for internet services. I'm interested on a work experience in USA for my study. If anyone is interested, or just wants to have a nice conversation with a German guy, just write to me, thanks!

See https://drupal.org/node/700538 and just add a sub-section to https://drupal.org/node/1121614 using the style of that page.

I will like to know if the default domain feature has been commited to the 7.x-3.x-dev version. If not when will it be committed. Thank you

careless, see #115

And I'd like to get it documented before rolling a release.

Sorry, I am busy on my vacation, but now I've just spent some time for documentation.
Updated Node Access 'Assigning Domain Access' section and added sub-section to Advanced Module Configuration. I hope it's ok so far, but I think some grammar correction is neccessary. Sorry for that.

I have time, and i will like to help with the documentation. What can i do to help

You could help me with reading these parts of the documentation: https://drupal.org/node/1121614#contentdefaults & https://drupal.org/node/1096982 (only the section Assigning Domain Access) and then tell me if you understand it. You could also tell me if something important is missing.

That's a real nice start. Does need a reviewer other than me to check for clarity, though.

Thanks. I will check them out and get back to you

Some of you seem to need a lot time to check 14 lines of documentation, huh?

@hauptm

And what have you done to move this forward?

Please, think before you speak.

I can hardly say that my own documentation for this feature is understandable and complete for everyone. So what I have done is waiting for almost 2 months to get feedback, as posted in #126. As we have 20 followers here, 17 other persons could have checked in this time. So I thought before speaking, but thanks for the hint. Also,#127 was not meant to attack anyone of you, it was meant as a jestingly reminder. I'm sorry for the disaccord.

No, it's my fault, I didn't read the backscroll to see that you had written the original docs.

My apologies.

No worries.

Interesting project!

I have running few domains and subdomains and one forum. I have few forum category and thanks to redirection I link them to proper domains/subdomains, for example:

forum category computers move user to computers.mypage.com/forum/computers and forum category drupal move users to drupal.mypage.com/forum/drupal. The problem is when users making new forum topic in computer forum section, it should be created with source domain - computers.mypage.com and again if they create a drupal topic the source page should be drupal.mypage.com

So if I get this right thanks to this patch I can make it work just fine ?

No, this patch is not for the Domain Source submodule. It only handles default publishing options for nodes.

Ohh,ok. Thanks for clarifying this out.

I was just looking at this code in light of #1616402: Convert domain_roles to use machine names, and it doesn't appear to me that the update hook actually converts old settings from using domain_id to using machine_name.

That seems like a pretty big oversight.

Wait. Ignore that. Those are new settings ;-p/.

That's a real nice start. Does need a reviewer other than me to check for clarity, though.

I think this task is still open for this one.

agentrickard, feel free to mark it as fixed again if you think the documentation is good enough so far. I just don't want to let things being overseen.

I like the online docs. They could be improved but are not a blocker. Thanks!