You are here

README.txt in Domain Access 6.2

README file for Domain User.

File

domain_user/README.txt
View source
  1. /**
  2. * @file
  3. * README file for Domain User.
  4. */
  5. Domain User
  6. Creates unique subdomains for registered users.
  7. CONTENTS
  8. --------
  9. 1. Introduction
  10. 2. Installation
  11. 2.1 Dependencies
  12. 2.2 Domain User and User Registration
  13. 3. Permissions
  14. 3.1 Edit Domain Nodes
  15. 4. Configuration Options
  16. 4.1 Module Behavior
  17. 4.2 Root Domain Name
  18. 4.3 User Domain URL Scheme
  19. 4.4 User Login Behavior
  20. 4.5 Assigned User Domains
  21. 4.6 Domain Table Prefixing *
  22. 4.7 Reserved Usernames
  23. 4.8 Domain Settings Page
  24. 5. Developer Notes
  25. 5.1 hook_user() Implementation
  26. 5.2 Domain API Hooks
  27. 5.3 Database Schema
  28. * Requires the Domain Prefix module.
  29. ----
  30. 1. Introduction
  31. The Domain User module is a node access module that allows for the automatic
  32. creation of subdomains for your users.
  33. By design, this module will allow user "JohnDoe" to create the following active
  34. domain:
  35. johndoe.example.com
  36. Note that all non-alphanumeric characters will be replaced with a dash, so that
  37. the user "John Doe 222" will create the subdomain:
  38. john-doe-222.example.com
  39. I recommend that you set the "Content editing forms" setting in the main Domain
  40. module to "Take user to their assigned domain." Doing so will force all content
  41. that a user creates to be assigned to his or her personal domain.
  42. Please read the documentation for the main Domain Access module carefully before
  43. you attempt to install and use this module.
  44. This module is not intended for use if you do not wish to perform node access
  45. control. It is not suitable simply for creating subdomains for your users.
  46. ----
  47. 2. Installation
  48. Domain User is included in the Domain Access download. To install,
  49. untar the domain package and place the entire folder in your modules directory.
  50. When you enable the module, it will create a {domain_user} table in your
  51. Drupal database.
  52. ----
  53. 2.1 Dependencies
  54. Domain User requires the Domain Access module be installed and active.
  55. ----
  56. 2.2 Domain User and User Registration
  57. Because Domain User tries to create subdomains for your users, the module could
  58. cause a conflict if you have previously created domains for your site.
  59. For example, you have used the Domain Access module to create the following:
  60. -- boston.example.com
  61. -- newyork.example.com
  62. -- sydney.example.com
  63. If a user tries to register for your site using the username "boston" or
  64. "sydney," the Domain User module would try to create a domain that already
  65. exists.
  66. To prevent this issue, previously created domains also create records in the
  67. Drupal {access} table. This table stores the rules for creating usernames when
  68. registering for your site.
  69. In effect, any domain that exists places a username restriction rule into your
  70. Drupal configuration. You can see the list of these "Reserved Usernames" on
  71. the Domain User settings page.
  72. ----
  73. 3. Permissions
  74. Domain User adds one permission to your Access Control page:
  75. -- 'create personal domain'
  76. Allows users to create a personal domain when registering or
  77. updating their accounts.
  78. -- 'create user domains'
  79. Allows a site administrator to create user domains on behalf
  80. of some other user.
  81. Only roles that have this permission can create personal subdomains.
  82. If you want users to be able to create subdomains when they register, you must
  83. give this permission to the 'anonymous users' role and to the 'authenticated
  84. users' role.
  85. If you are assigning additional roles during account creation, you may also need
  86. to grant the 'create personal domain' permission to those roles as well.
  87. Users with this permission will have their personal domain created either:
  88. on registration or on updating their account.
  89. ----
  90. 3.1 Edit Domain Nodes
  91. By design, all users will be assigned to the Domain that they create. This
  92. grants them access to edit nodes posted to their domain. To enable this
  93. feature, a user must have the "edit domain nodes" permission granted by
  94. the core Domain Access module.
  95. ----
  96. 4. Configuration Options
  97. Domain User has its own settings page at Admin > Build > Domains > User
  98. domain settings. The following options are available.
  99. ----
  100. 4.1 Module Behavior
  101. Controls when (and if) user domains should be created. The following options
  102. are available:
  103. -- Do not create domains for users [Default]
  104. -- Automatically create domains for new users
  105. -- Ask users if they would like to create a domain
  106. Note that "do not create" is the default setting. This prevents domains from
  107. being created before you finish configuring the module.
  108. If you select "ask users," then a checkbox option will appear to users during
  109. registration (or account editing) if the following conditions are true:
  110. -- The user has permission to create a domain.
  111. -- The user has not created a personal domain.
  112. Note that currently there is no way for a user to delete their own domain. If
  113. a user account is blocked, access to the user domain is blocked. If a user
  114. account is deleted, the user domain record is also deleted.
  115. ----
  116. 4.2 Root Domain Name
  117. The root domain to use for creating user domains, typically example.com. No
  118. http or slashes.
  119. When users create domains, their username will be added to the root domain to
  120. create a custom domain. For example, user.example.com or administrator.example.com.
  121. All user domains follow the pattern:
  122. username.example.com
  123. Where example.com is the "Root domain name" configured here.
  124. In theory, you may use a multi-level domain scheme here, such as:
  125. username.personal.example.com
  126. When entering your root domain, you should not include the username
  127. string.
  128. WARNING: Your web server must be configured to recognize these domains
  129. for them to function. Wildcard DNS is the preferred solution for handling
  130. user domains.
  131. ----
  132. 4.3 User Domain URL Scheme
  133. Allows user domains to be prefixed with either http:// or https:// protocols.
  134. Note that all user domains will be created using the same scheme.
  135. Changing this setting will _not_ affect domains created prior to the change.
  136. ----
  137. 4.4 User Login Behavior
  138. Controls the behavior of the module when a user with an existing personal
  139. domain logs in to the site. Options are:
  140. -- On login, go to personal domain [Default]
  141. -- Do not go to personal domain on login
  142. Because of how Drupal login works, this feature uses a session variable to
  143. trigger the redirect.
  144. ----
  145. 4.5 Assigned User Domains
  146. Controls which domains a user is assigned to for editing purposes. The options
  147. are:
  148. -- Assign only to the user domain [default]
  149. -- Assign to both user domain and active domain
  150. NOTE: If a user domain is deleted, the user will be assigned to the primary
  151. domain.
  152. ----
  153. 4.6 Domain Table Prefixing *
  154. This setting is only available if you have the Domain Prefix module turned on.
  155. Since Domain Prefix is a powerful module that creates extra database tables,
  156. you have the option to selectively disable that module for user-created domains.
  157. Options are:
  158. -- Never create prefixed tabled for user domains [Default]
  159. -- Obey the settings in Domain Prefix
  160. Note that "obey the settings" may not create tables when the domain is created,
  161. since Domain Prefix has its own behavior settings.
  162. ----
  163. 4.7 Reserved Usernames
  164. At the bottom of the Domain User settings page is a list of all reserved
  165. usernames. This list is derived from the administrator-created list of domains.
  166. Users should not be able to register or login with any username listed here.
  167. ----
  168. 4.8 Domain List Page
  169. Note that on the main Domain list page at Admin > Build > Domains > Domain
  170. list, a new column is added to the domain table. This column shows the username
  171. of the
  172. ----
  173. 5. Developer Notes
  174. This module has been tested for base functionality. There may be edge cases
  175. that it does not properly address.
  176. Please file bug reports if you encounter any problems.
  177. ----
  178. 5.1 hook_user() Implementation
  179. Domain User implements hook_user() to perform many of its functions. The
  180. module also will add a 'Personal web site' element to the user profile of any
  181. user who has created a personal domain.
  182. ----
  183. 5.2 Domain API Hooks
  184. Domain User leverages some of the internal APIs of the Domain Access module.
  185. -- domain_user_domainload() adds the UID to the global $_domain array and
  186. to all $domain lookups.
  187. -- domain_user_domainupdate() implements the 'delete' hook in order to
  188. delete records from {domain_user} in the event that the administrator
  189. deletes a user domain record.
  190. -- domain_user_domainview() adds the additional information column to the
  191. Domain list page.
  192. For more information, see http://therickards.com/api/group/hooks/Domain
  193. ----
  194. 5.3 Database Schema
  195. Installing the module creates a {domain_user} table that contains:
  196. - domain_id
  197. Integer, unique (enforced by code)
  198. The lookup key for this record, foreign key to the {domain} table.
  199. - uid
  200. Integer, unique (enforced by code)
  201. The lookup key for this record, foreign key to the {users} table.