Site membership plugin

13 posts by 4 authors in: Forums > CMS Builder: Plugins & Add-ons
Last Post: January 10, 2011   (RSS)

By (Deleted User) - October 16, 2010

Hi,

We downloaded the Site Membership plugin which uses the users table in the database which stores the usernames and passwords. However, we are developing a recruitment website which requires a user profile. We want to store the profile info (qualifications, work experience, CV etc) into another table on the same database, but have the two tables display on the same page.

We want to gather the information together using the unique number (the num field that is used in both tables), so the number in the num cell should be the same.

Are you able to help us?

Please find attached two jpgs which are screen shots of the relevant tables in the database.
Attachments:

accounts.jpg 309K

hompages.jpg 242K

Re: [mgobey] Site membership plugin

By Jason - October 18, 2010

Hi,

Since there will be only one profile for the user, you can store the profile information inside the accounts table. Inside CMS Builder you can add as many fields as you want to the accounts section and it won't affect how the membership plugin works.

If you need them to be in separate tables, what you would need to do is have a field in your profile table that stored the num field from the accounts table. That way you can find the profile based on their user number.

Hope this helps.
---------------------------------------------------
Jason Sauchuk - Project Manager
interactivetools.com

Hire me! Save time by getting our experts to help with your project.
http://www.interactivetools.com/consulting/

Re: [Jason] Site membership plugin

By (Deleted User) - October 19, 2010

Hi, [/#000000]

Thanks for the post.[/#000000]

We would like to have two user types, the first user a job seeker which will have relevant profile info including up-loadable CV and the second profile would the employer with their relevant details.[/#000000]

We thought it would be best practise to use the account table as used in the Site membership plug-in to store the basic and common logon details and have another two separate tables that would be used to store the job seeker profile and the employer profile.[/#000000]

Note we would only need the job seeker to signup online and we would add the employers manually.

What we really need to understand is how we can copy the num value to relevant table and display and edit it through the Site membership plug-in.

Kind regards

Michael

Re: [mgobey] Site membership plugin

By Chris - October 19, 2010

Hi Michael,

I think you're on the right track. I would add a `type` List Field to the `accounts` table so that you'll know whether you've got a "Job Seeker" or "Employer" account immediately. Your `job_seeker_profile` and `employer_profile` tables can be Multi Record sections in CMS Builder - you'll just need to add a List Field to reference the correct account:

Field Label: Account
Field Name: account
Field Type: list

Display As: pulldown
List Options: Get options from database (advanced)
Section Tablename: accounts
Use this field for option values: num
Use this field for option labels: fullname

Then, on front end pages, you can get the associated record like this:

<?php

if (!$CURRENT_USER) { websiteLogin_redirectToLogin(); }

if ($CURRENT_USER['type'] == "Job Seeker") {
list($job_seeker_profileRecords, ) = getRecords(array(
'tableName' => 'job_seeker_profile',
'where' => 'num = ' . mysql_escape($CURRENT_USER['num']),
'allowSearch' => false,
));
$job_seeker_profile = @$job_seeker_profileRecords[0]; // get first record
if (!$job_seeker_profile) { die("Couldn't find job_seeker_profile!"); }

echo "Hello Job Seeker!";
showme($employer_profile);
exit();
}
elseif ($CURRENT_USER['type'] == "Employer") {
list($employer_profileRecords, ) = getRecords(array(
'tableName' => 'employer_profile',
'where' => 'num = ' . mysql_escape($CURRENT_USER['num']),
'allowSearch' => false,
));
$employer_profile = @$employer_profileRecords[0]; // get first record
if (!$employer_profile) { die("Couldn't find employer_profile!"); }

echo "Hello Employer!";
showme($employer_profile);
exit();
}
else {
die("invalid account type");
}

?>

What we really need to understand is how we can copy the num value to relevant table and display and edit it through the Site membership plug-in.


In the sample_signup.php script that comes with the Website Membership plugin, the `num` field is gotten after the INSERT via this code:

$userNum = mysql_insert_id();

If you want to create the associated `job_seeker_profile` record then, you'll use that value to reference the `account` record you just created.

Does that help? Please let me know if you have any questions.
All the best,
Chris

Re: [chris] Site membership plugin

By (Deleted User) - January 9, 2011

Hi Chris
Thanks for the response on this it has been a while since I have had to look at this I have followed your instruction and it works well in part well.

But what we would like to achieve is the ability for a job seeker to sign up for and account using the site membership plug-in and at the points of the signing up for account the association between the accounts table and the job seeker table is made and when the job seeker log in they can update their account and the job seeker pacific info to be stored in the associated job seeker profile table.

Regards

Re: [mgobey] Site membership plugin

By Jason - January 10, 2011

Hi,

There are two ways you can do this. If you want to have a separate jobSeeker table, then after you create the account in the accounts table, you'll need to create another record in the jobSeeker table. You'll need a field in the jobSeeker table where you can store the record num of the accounts record you just created.

Another way, would be to add fields to your accounts section to store their profile information. This way you can still allow them to edit their profile information without having to create a second record. This way would probably be the most straight forward.

Hope this helps.
---------------------------------------------------
Jason Sauchuk - Project Manager
interactivetools.com

Hire me! Save time by getting our experts to help with your project.
http://www.interactivetools.com/consulting/

Re: [Jason] Site membership plugin

By (Deleted User) - January 10, 2011

Hi there thanks for your response

I have had a thought. I agree the second option would probable be simplest

Is there a way that we could maybe use the excising account table and have an additional two separate sections editors linking to the same table for example have the accounts table storing all user data with the addition of a type field. Then display the relevant results to the appropriate section editors based to the type

Thanks Michael

Re: [mgobey] Site membership plugin

By Jason - January 10, 2011

Hi Michael,

I'm not sure I understand what you want to accomplish. It would be possible to associate a single accounts record with records in other sections. However, if there isn't a really good reason for having the data spread out across multiple sections, then you'd probably be better off storing all your stuff in the accounts section.

What would be stored in these other section editors? How do you want to associate them? How do you want to access them?

Let me know.
---------------------------------------------------
Jason Sauchuk - Project Manager
interactivetools.com

Hire me! Save time by getting our experts to help with your project.
http://www.interactivetools.com/consulting/

Re: [Jason] Site membership plugin

By (Deleted User) - January 10, 2011

Hi

What I am trying to a achieve is to separated the jab seekers and employers to make it easier for the client to view and edit the relevant users on the site by type.

For example when the client wants to see the latest job seeker that has signed up or employer they can go striate to relevant section with out having to search by type and more interpolate we can exclude or hide certain fields that are not relevant to a to a job seeker or employer depending in witch section the client is in

note I realise that much of the data is the same for both job seeker and employer and in practices it is fine to store all the data in the same table in the bake end. But as fore as the client can see it would grate if it appears separate secessions

Thanks Michael