I'm currently building a site using domain access. So far I like it a lot, I'm really glad this module exists, job well done! :-)
In this particular case my users will create new 'subsites' themselves. I already succeeded in making a very simple form with only two fields that they can fill out. This form creates a new domain record (using drupal_execute on the correct form id) and creates a new menu, because I want each site to have it's own primary links menu. The challenge I'm facing now, is to programmatically assign this new primary links menu to the domain that was just created. I could do this of course by querying the domain_conf table, unserializing the data, modify it, serialize it again, and update the table. I consider that hacking though, as I'm sure this is not guaranteed to work in future versions.
I tried to come up with a way of doing this through the functions defined in domain_conf, but I guess the problem is that domain_conf relies on the current domain being the one you're editing. I would like all this to be done invisible to the end-user.
So my question is: is there a better, more "official" way to do this? Any hints? Your help is greatly appreciated!
Comments
Comment #1
agentrickardThere really is no better method than what you describe.
However, I would be willing to commit a patch for a new function, domain_conf_set_variable(), which would have the following structure:
Then we can put your code into the main module so we don't have to worry about deprecation, since this becomes an API function.
Comment #2
svdoord commentedIt seems to me like a good idea to add a facility for this to the API. I don't have any code yet for the suggested method I described above, so I'm afraid you cannot put my code there :-)
Meanwhile, I have been able to solve my issue in a better way than the one I suggested first. I use the following code now, which is called from hook_domainupdate() in my custom module (when $op == 'create').
So the trick is basically to use a normal drupal_execute, but because I manually change $_GET['q'], I trick domain_conf into using the correct settings entry. To me this solution is acceptable, because I don't need to access the database and rely on the internals stored in the domain_conf table.
Again, an API function like the one you suggest would be a very nice addition. I would then not even have to rely on the fact that domain_conf_system() uses arg(4) to determine the current domain. By the way, I'm not entirely sure if I should use domain_conf_domainlinks(), but I also don't want to put the literal URL in my module (because it's an internal of the domain access module).
Comment #3
agentrickardI have committed this function to HEAD. Here is the API documentation.
Comment #4
allella commented@agentrickard - any interest in adding the sort of feature svdoord described if some like me is willing/able to develop it? I could use this functionality as well for a client project and wouldn't mind building it into Domains.
I think some of the code above could be used as a start. I'd likely try to create each primary links menu using drupal_execute() to simulate how a users create new menus in Drupal. Also adding at least one checkbox to the general Domains settings to control whether to auto-generate primary links. Or else, adding an option on the Domain creation form.
Menu Names in Drupal core are limited to 27 characters and technically the menu_name value shouldn't change once set, so this would require a bit of thinking to build something that works well with Drupal Core, the Domains modules, and is still obvious to end users. Perhaps using domain-{domain_id}-primary , or some such.
Anyway, I figured I'd gauge interest.
Comment #5
agentrickard@orangecoat-ciallella -
Please open a new issue that describes what you are trying to do.
Comment #6
gunzip commentedyou can prefix the menu tables (so each domain has its own one) then
you can execute any functions in the scope of any domain with a code like that one posted here:
http://drupal.org/node/343281#comment-1195947
Comment #7
agentrickard