| 1 |
$Id: $
|
| 2 |
This module adds the ability to have several different membership types, each collecting different
|
| 3 |
data from the user for registration by using custom content types and the combination of nodeprofile
|
| 4 |
and pageroute modules. The accounttypes module is recommended but not required.
|
| 5 |
|
| 6 |
--CONTENTS--
|
| 7 |
REQUIREMENTS
|
| 8 |
SETUP/INSTALL
|
| 9 |
FEATURES
|
| 10 |
USAGE (Example)
|
| 11 |
UNINSTALL
|
| 12 |
CREDITS
|
| 13 |
|
| 14 |
--REQUIREMENTS--
|
| 15 |
This module requires the use of the pageroute and nodeprofile modules. The section on USAGE will
|
| 16 |
explain how to use them. The usernode module should not be used. Any other requirements of either
|
| 17 |
the nodeprofile or pageroute modules will also naturally be required. See their respective
|
| 18 |
documentation for more information.
|
| 19 |
|
| 20 |
The accounttypes module is not required, but is recommended. One would normally think of account
|
| 21 |
types and membership types to be the same thing. In this case, they can be, but don't have to be.
|
| 22 |
Account types limit the roles available to a user and can be automatically assigned via this
|
| 23 |
module based on memebership type. See the accounttypes documentation for more information on what
|
| 24 |
it does, along with the USAGE example below for how I use it.
|
| 25 |
|
| 26 |
--SETUP/INSTALL--
|
| 27 |
Before you activate this module you should probably do these things:
|
| 28 |
1) Install the nodeprofile module.
|
| 29 |
2) Install the pageroute module.
|
| 30 |
3) Outline the membership types you would like to have and the data you would like to collect
|
| 31 |
from each group of users. Identify which fields are in common and which are not.
|
| 32 |
4) Identify which fields you would like to require, and which you don't.
|
| 33 |
5) Create the content types based on your observations in steps 3 & 4 such that you minimize
|
| 34 |
the number of pages, but separate required/non-required, and common/non-common items. This
|
| 35 |
may result in one or more content types with only one field, depending on your situation.
|
| 36 |
That's okay!!! With the pageroute wizard system, it really isn't important to jam a page full
|
| 37 |
of fields, and in my opinion, looks cleaner anyway.
|
| 38 |
6) Make sure you've setup your roles and permissions how you want them. If you use the accounttypes
|
| 39 |
module, you will keep in mind to make roles more granular than you might otherwise. If you'd
|
| 40 |
like to use the accounttypes module, enable and set it up at this point.
|
| 41 |
6a) In setting up the accounttypes module, you can either create an account type for each
|
| 42 |
membership type (as I have) or not. It may be in your case that you would like to allow two or
|
| 43 |
more different account types for one membership type. You may, for example have an administrator
|
| 44 |
membership type and wish to have both a junior and senior administrator account type that could
|
| 45 |
be assigned to that membership type. Be careful to note that this module assigns a default
|
| 46 |
account type (if you've set that up) at both account creation, and by changing membership type
|
| 47 |
at the mass-user edit screen. More on that below.
|
| 48 |
7) Copy the module's files into your site's module folder per standard Drupal practices.
|
| 49 |
8) Enable it at the module administration screen.
|
| 50 |
9) There is no install file as no database table needs creation. The standard variables table is
|
| 51 |
used for global settings and user data is stored in the user's 'data' field.
|
| 52 |
|
| 53 |
--FEATURES--
|
| 54 |
Now follows an overview of each setting, where to find it, and what it does.
|
| 55 |
1) At registration, users will first be presented with a membership type selector. After selecting
|
| 56 |
the membership type, they will fill out the standard registration form. After that, as noted
|
| 57 |
below in B->III, the user will travel a pageroute to fill out more information.
|
| 58 |
2) admin/user/nf_registration_mod
|
| 59 |
This is the primary location for the settings of this module. You should see an added menu item
|
| 60 |
in the 'User management' section called 'Registration Membership Types'. Clicking that gets you here.
|
| 61 |
A) On the main or 'Overview' page, you will see three (or four) tabs across the top, a blank text
|
| 62 |
field with a button, and a blank text area and another button. The tabs are explained below.
|
| 63 |
I) The text field is in a table and, above, it has the label of 'Membership title'. This is where
|
| 64 |
you type in the name of each membership type in turn. Clicking on the button 'Add membership
|
| 65 |
type' will add the name to a global setting. You can add as many membership types as you wish
|
| 66 |
before proceeding with the form described in the next section (II), or you can alternate
|
| 67 |
between I and II.
|
| 68 |
II) Once you've added a membership type, there will be an empty drop down list in the 'pageroute'
|
| 69 |
column of that new type, along with a new button 'Add pageroute tie'. You should have already
|
| 70 |
created your pageroutes and if you did, you can choose one here. I'm using the term 'tie' to
|
| 71 |
indicate that a relationship has been made, usually with something from another module, that
|
| 72 |
this module does not directly control nor infulence, but uses in some other way.
|
| 73 |
III) The delete link in each row will of course present you with a choice to really delete that
|
| 74 |
particular membership type or not. There's a note that says your pageroute will not be
|
| 75 |
destroyed via this module, but that you can use the pageroute module if you intend to get rid
|
| 76 |
of that as well.
|
| 77 |
IV) The edit link takes you to an edit page where you can change both the name and pageroute for
|
| 78 |
a given membership type. There is currently no method to edit multiple membership types and
|
| 79 |
there are no plans to do such since I can't think of a use-case where more than a dozen
|
| 80 |
membership types would be used and anything less should be easily managed as-is.
|
| 81 |
V) The 'User instructions' text area is a place where you can enter the instructions required for
|
| 82 |
a user to correctly choose between the membership types you are providing. This can be changed
|
| 83 |
here directly whenever you need to. Click the 'Save message' button to save it.
|
| 84 |
NOTE: in both III & IV above, updates to the account type ties are maintained.
|
| 85 |
B) The next tab is 'Content type adjustments' (admin/user/nf_registration_mod/ct_adjustments).
|
| 86 |
Because the content types you created for node profiles should not be treated as regular content
|
| 87 |
types, this area both shows you some default changes this module makes and allows you to make
|
| 88 |
others. The page is organized by content type. The path of each is shown, as is which pageroutes
|
| 89 |
use it and what the pages are called in each pageroute.
|
| 90 |
I) Actually, in looking at the screen again, I see that I didn't give you an indicator that the
|
| 91 |
pageroute menu items are disabled, but that's what happens by default.
|
| 92 |
II) There is a note that advises you to disable all content type links for those types related
|
| 93 |
to the pageroutes you've setup. You check the items you want to disable and click on 'Disable
|
| 94 |
menu items' to affect that change. This does not delete the menu item. If you were to go to
|
| 95 |
the regular menu admin, you would see them, but they'd be disabled. This removes the 'Create
|
| 96 |
content' menu items as well as those on the content type page when you have clicked 'Create
|
| 97 |
content' and haven't selected a type yet. This module is aware of my 'Content type
|
| 98 |
Administration by Organic Groups' module and removes these types from the relevant admin
|
| 99 |
pages. It also adds these types to the OG omiited content type list which prevents groups
|
| 100 |
from using them.
|
| 101 |
III) If you wish to prevent users from using your site until they've completed some or all of
|
| 102 |
a given pageroute, you can specify which content types are required. For this reason, I made
|
| 103 |
the suggestion in the SETUP section above for how to segregate the content fields as you
|
| 104 |
create your content types. For example, you may require a full name and an address for all
|
| 105 |
users. Place that on one content type and require it on this page. You might have another
|
| 106 |
content type just for corporate accounts that have other required info. Put that on another
|
| 107 |
content type. Presumably, you'd have at least two pageroutes. One would have that first
|
| 108 |
required type, the other would have both required types. You could then add other content
|
| 109 |
types for non-required info. Check the boxes for the types you want to require and then click
|
| 110 |
'Require for login'.
|
| 111 |
|
| 112 |
WHAT THIS ACTUALLY DOES is reroute users who have not made nodes of the required types to the
|
| 113 |
next required type that they need to make. This happens both at login and any time the user
|
| 114 |
tries to browse away using any link on the page except the logout link.
|
| 115 |
|
| 116 |
Some of how this works depends on the settings you made for registration. If you require that
|
| 117 |
a user be validated by an admin, then the user will not be able to fill these nodes out until
|
| 118 |
they are unblocked. If you have required email verification, the user will be logged out right
|
| 119 |
after selecting a membership type and filling out the standard registration form. They will
|
| 120 |
be able to fill out the required nodes once they've verified their email address and come back
|
| 121 |
to the site. If you have neither required email verification, nor admin approval, then the
|
| 122 |
user will be able to fill out the nodes right away.
|
| 123 |
|
| 124 |
If a user quits their session/logs out before completing all required content types, they will
|
| 125 |
be presented with the next content type they need to complete and a total listing of pages to
|
| 126 |
submit. If you use the pageroute settings as outlined in the USAGE example, this will keep your
|
| 127 |
users from getting confused as to what is required of them.
|
| 128 |
NOTE: Because this screen has two buttons which use the same checkboxes, rather than check the
|
| 129 |
boxes of previously disabled/required types for you, all checkboxes default to unchecked. This
|
| 130 |
means that you must re-check previously affected types if you are making ANY changes or else they
|
| 131 |
will be undone. For this reason, I've provided the 'Status' column so you can see what state each
|
| 132 |
type is in.
|
| 133 |
CAUTION: Hmm, I thought of one two paragraphs ago, but now can't remember.
|
| 134 |
C) The next tab is 'Set access' (admin/user/nf_registration_mod/set_access) and is a placeholder
|
| 135 |
for now. What I would like to do is show a slice of the permissions page so that you can assign
|
| 136 |
only those permissions to roles that pertain directly to the content types we are dealing with
|
| 137 |
on these particular pageroutes. A first look leads me to believe that I need to work on the full
|
| 138 |
array of permissions. So even though I would only show a slice, I would have to keep track of
|
| 139 |
all permissions for all roles. This would require duplicating a lot of code from the standard
|
| 140 |
user module. I'm hoping there's a better way, so I've put this on the back burner. So instead,
|
| 141 |
I've provided some little bit of instruction as to how to set your content type permissions
|
| 142 |
as well as a link to the regular permissions page.
|
| 143 |
|
| 144 |
To summarize how you may want to set permissions, you first need to determine which types you
|
| 145 |
want users to edit after creation. If you don't want the user to edit their node, be sure to
|
| 146 |
not integrate it with profile categories in the nodeprofile settings of the content type. If
|
| 147 |
a user cannot edit their own node, then they cannot view it either. In my case, I am allowing
|
| 148 |
both 'create' and 'edit own' permissions for all content types, then restricting the individual
|
| 149 |
fields with another access control module. You could do the same, or you could disallow 'edit
|
| 150 |
own', still enable profile category integration, then use a module like TAC to somehow give
|
| 151 |
the 'view' grant only. This is a complicated issue, so any variations from the USAGE example
|
| 152 |
below are up to the user to figure out. Feel free to share your particular setup with us in
|
| 153 |
the issue queue.
|
| 154 |
D) The fourth tab only shows up if you've enabled the accounttypes module. The tab is labeled
|
| 155 |
'Tie account type to membership' (admin/user/nf_registration_mod/account_type). On this page
|
| 156 |
you can set a default account type to be given to a user whenever their membership type
|
| 157 |
changes to that membership type.
|
| 158 |
I) This is a straight-forward page where each membership type is displayed and there is a
|
| 159 |
drop down next to each to choose which account type to associate with it. Select the one
|
| 160 |
you want and click 'Save assignments'.
|
| 161 |
II) If you don't want all of your membership types to be associated to an account type, too
|
| 162 |
bad. The workaround is to create an account type (or use the 'basic' one that comes with
|
| 163 |
the accounttypes module) and then not assign it any roles, or assign it all roles -
|
| 164 |
whichever makes sense for your situation.
|
| 165 |
|
| 166 |
--USAGE--
|
| 167 |
This outlines not only the suthor's settings for this module, but also for the nodeprofile and
|
| 168 |
pageroute modules. This should more or less guaranty decent results.
|
| 169 |
First let me tell you the versions of the modules' files used [not module version, but file]:
|
| 170 |
nodeprofile.module - 1.7.2.14
|
| 171 |
pageroute.module - 1.39.2.26
|
| 172 |
pageroute_subform.inc - 1.1
|
| 173 |
pageroute_ui.module - 1.29.2.6
|
| 174 |
So figure out which releases these correspond to. I can't say for certain whether later versions
|
| 175 |
will work the same or not as I'm not the author of them.
|
| 176 |
1) After installing the nodeprofile module and the pageroute module, I decided to create three
|
| 177 |
membership types. I then outlined the data I needed to collect from each. I saw that some was
|
| 178 |
common between two or more membership types. Beginning with what was common, I further divided
|
| 179 |
that information into required and non-required status. I then made my first content type using
|
| 180 |
the common & required fields (PAGE2). I then moved to the common & non-required information.
|
| 181 |
This data fit on two content types nicely (PAGE3 & PAGE4). Then I had three required but not
|
| 182 |
common content types to create (PAGE1, PAGE1A & PAGE1B). I then determined what the flow
|
| 183 |
through each pageroute should be, hence the page names above. The settings for all of this
|
| 184 |
follow.
|
| 185 |
2) The first settings to manipulate are in each content type's edit page
|
| 186 |
(admin/content/types/YOUR_TYPE). Here, I unchecked all default options, set maximum population
|
| 187 |
to 1, checked the 'Use this content type as a nodeprofile for users' box, disbaled comments,
|
| 188 |
and unchecked or disabled everything else (from various modules I had enabled).
|
| 189 |
3) After saving the changes and returning to the same edit page, I then clicked in the 'Node
|
| 190 |
profile' tab (admin/content/types/YOUR_TYPE/nodeprofile). Here, I checked the 'Integrate this
|
| 191 |
node profile with user categories.' box. I then selected the 'Don't display this nodeprofile
|
| 192 |
on the user account page' radio button and set the weight depending on the order of that
|
| 193 |
content type within the pageroute(s) it would be in; the first was lightest.
|
| 194 |
3a) I'm not sure that I needed this or not, so I'll mention this in passing. I hope this wasn't
|
| 195 |
required since I didn't put in on the requirements list, but I did use the nodefamily module.
|
| 196 |
Because I have three page ones (PAGE1, PAGE1a and PAGE1b), I made them each parents and then
|
| 197 |
made each content type that would be in its pageroute a child. Because there are content
|
| 198 |
types in common, those types appear as children to more than one parent. The admin for
|
| 199 |
nodefamily is here: admin/content/nodefamily.
|
| 200 |
4) Next I worked on the pageroutes at admin/build/pageroute. First thing I did there was create
|
| 201 |
the routes at admin/build/pageroute/add using the 'add route' tab. I named the path, then
|
| 202 |
deselected the workflow option, selected 'Show tab-like submit buttons above the page content.',
|
| 203 |
assigned the appropriate roles to it, selected one of the PAGE1's for the nodefamily head,
|
| 204 |
set the 'Customized redirect' to user/!uid, and checked 'Preserve destination parameter during
|
| 205 |
this route.'
|
| 206 |
5) Then I added the pages to each route. That is done from the 'Add page' tab
|
| 207 |
(admin/build/pageroute/route/YOUR_ROUTE_NUMBER/add). Because each of my content types was given
|
| 208 |
a population maximum of one above, they are called 'lonely nodes' and so at the first screen
|
| 209 |
of the add wizard, I selected 'Lonely node management' type. This takes you to the same page
|
| 210 |
as what is later the page-edit page. When you edit the page later it will be found here:
|
| 211 |
admin/build/pageroute/route/YOUR_ROUTE_NUMBER/edit/YOUR_PAGE_NAME. At this point, I gave the
|
| 212 |
page a name, left the title blank, and checked the 'Activated' box. I skipped the 'dont show
|
| 213 |
a tab for this page' section, selected the content type that should be associated with the
|
| 214 |
step in the pageroute, left the cancel link label empty, labeled the 'Forward button label'
|
| 215 |
as 'Next page' because that's what this module uses for the membership page, and labeled the
|
| 216 |
'Back' button 'Back'. Then of the three checkboxes, I only checked 'Never display the delete
|
| 217 |
button' because I don't want users to delete this information; I only want the admins to do
|
| 218 |
that. Again, I set the weight according to the page order, the first being the lightest.
|
| 219 |
6) Now, unless I'm forgetting something, that should be everything to setup content types,
|
| 220 |
nodeprofiles, nodefamily, and pageroutes. Next is the configuration of this module.
|
| 221 |
7)Nearly all steps I took to setup this module are obvious, so I'll direct you to the FEATURES
|
| 222 |
section above. I will say that on the admin/user/nf_registration_mod/ct_adjustments page, I
|
| 223 |
disabled all content types, and required those that I planned to be required from the start.
|
| 224 |
I also set the appropriate roles to have access to both 'create' and 'edit own' for each
|
| 225 |
content type in the pageroutes. Last, I associated an account type with a membership type.
|
| 226 |
That's it!
|
| 227 |
If anyone has questions regarding the process above, please feel free to open a support issue.
|
| 228 |
But like I said, variations from this recipe will result in a varied outcome.
|
| 229 |
|
| 230 |
--UNINSTALL--
|
| 231 |
Because this module doesn't create or maintain its own database tables, you can disable the module
|
| 232 |
and don't need to visit the uninstall page. Just in case you want to disable this and then reenable
|
| 233 |
it later, I don't delete the entries this module makes in the variables table, nor do I delete the
|
| 234 |
entries to each user's data field. I figure that for the vairables, it's easy enough for most admins
|
| 235 |
to delete them by hand. They all start with the prefix 'nf_registration_mod'. And since I only add
|
| 236 |
one piece of information to the user object, I figured you all wouldn't mind keeping it around. If
|
| 237 |
I get enough complaints, I guess I'll look into a more formal disable routine.
|
| 238 |
|
| 239 |
--CREDITS--
|
| 240 |
This module was created by Ryan Constantine (drupal id rconstantine)
|
Parent Directory
| 
Revision Log
| 
Revision Graph