function plugin_subscription_additional_data

Hallo Alex!

While studying the plugin.php, I came with the idea of suggesting a new function in the CORE files.

This will add an extra ordinary strength to the features and core...

Following are my suggestions:

1. To add an additional feature of aMember that would help the plugins to manage additional information in the plugin database. This would be a solution to all the CMS and other scripts on the level of plugin Architecture _THAT_REQUIRES_ extra information.

Due to the use of amember, the user is deprived of this possibility, which everyone knows.

Hence if there is a field mapping of plugins, which is what I have already suggested through the support, then it would be the easiest to have additional information for the plugins.

Hence for each subscription and plugin calls there could be a secondary function that could be called at the end of plugin_subscription_add/modify/delete...

2. Lets say there is a table with the name

amember_plugin_config

This table would know that are the fields in the plugin database that are mapped for the main subscription and what are the additional information fields that needs to be gathered for THAT plugin.

Here is the idea of GLOBAL INFORMATION AND LOCAL INFORMATION for the field data necessary.

For instance the global field information of data gets in each and every plugin and local data would enter ONLY in that plugin. and will not be distributed for other plugins.

Hence if the joomla plugin is used which integrates community builder, then following would happen:

A) usernames, passwords, etc would get updated globally for each and every plugins.

B) the details of profiles, etc would be called from the CB tables, allowing the users to add, modify and delete - only for the CB tables - that are mapped in the amember_plugin_config

So the aMember will generate a form _FROM_ joomla database, allow modifications and update the CB tables.

This should be not very difficult to implement. Generating forms function programming is there, connection to the database programming is done, configuring the additional member_fields is also done (but would need to modified), etc...

I would be very interested to hear from other users if something like this would also help them.

Hi Alex!

May be I was not clear enough!

Well, currently the aMember installation only handles the product pages. I suggest that aMember to also maintain extra pages in the remote/plugin installation.

This could be achieved by having extra function in each plugin through plugin.php named as subscription_extra_added, etc...

Hence this will allow to add, modify and delete extra pages, fields, tbles, etc in the plugin database tables that are different than User tables.

For example:

If I integrate community builder in joomla, how do I use it when the registration, login, etc works with aMember?

In my suggestion, I would have extra additional fields to be configured in the aMember mapped to community builder of joomla. Then aMember will generate a page to add, modify and delete record in community builder. So all will be done directly on the tables of community builder tables.

The same would be for e.g. xoops tables. aMember could have mapping in the amember_plugin_config and populate into xoops tables like forum, or other modules DIRECTLY.

So my suggestion is that aMember could have interfaces not only for the membership/products/subscriptions but also for other details that a plugin modules requires to maintain.

This will also not be difficult to add as most of the functions do exists.

Hi Alex!

Well, imagine that community builder does not exists in joomla. How can I create a website with similar features of community builder with the help of amember?

With my suggestion, it would be possible!!!

In my concept, you can create multiple configuration for each subscription (which you call then as products) and for each subscription you can then have multiple pages to be maintained by amember!!!

One configuration is to make profile pages. Second is to create job postings and so on. So the profile pages would be similar to community builder.

If community builder exists, then it should be possible to mapp the fields of community builder,capture the field data, display for modifications and save once again into community builder tables.

Advantages are:

1. A central system for all registered members to login only once. This helps especially when aMember is mapped to multiple domains.
2. A central data management that helps to make all available fields to all plugins and inter-exchange of those maintained data everywhere. Example: echo "$plugin.joomla.combuilder.universitydegree"; on xoops installation.
3. Multiple profiles like social profile, job profile, business profile and multiple profile/display names to be maintained into amember. Here aMember could maintain dating profile mapped with a phpmatchmaker, job profile mapped with joomla job-component, business profile mapped with directory of drupal, etc.
4. Create new potebtial to create and maintain new functions into plugins.

So the member has a centralised system and all th management also happens centralised.

The concept of aMember is to offer a centralised system to different technological situations within php-mysql, I mean CMS Joomla, CMS Xoops (well, Xoops is NOT a CMS though), CMS Drupal, etc.

Currently, aMember concept is developed only for those connection points and the interface is not explored enough, where I see a lot of potential.

So the profiles pages information/data must not be in aMember but only field configuration and mapping + a generic form rendering. Some aspects are already done and programmed.

Shall I give a bit more technical answer, I mean sketch of functions?

Hello Alex!

Further examples that strickes me:

Birthday and language of the member could be collected and centralised.

So for instance the parameter language=en could be passed on to xoops, joomla, etc and those respective languages would be shown...

Birthday could be passed on to the job-profile, or even a birthday greetings module...

And for instance the timezone.

Currently aMember integrates with all thr CMS. Thereafter the account changing in those CMS is prohibited for logical reasons. But those CMS do require certain other bacis and fundamental parameters that needs to be stored.

Hence this could be achieved like following:

Create a new table with field mappings of different CMS or scripts and thier field properties.

Create a field conrtainers data for the database and to display, i.e. db_name & display_name in mysql.

Then generate forms where the name=db_name.

Submit and store them into mysql aMember installation

OR

into the remote plugin database.

For e.g. the profiles info would be required only by the community builder. So one need not duplicate those data, once in aMember and the second in community.

However, through this system, aMember would know exactly where the data is to be found, within the aMember or wihin the remote and offer the user/amember all the add, modify, delete possibilities.

This will also help in generating additional subscription/products pages, a much required feature.