$member['data']['status']

Hallo Alex!

To work with this is a nightmare.

This needs a lot of processing power everywhere and the entire aMember Concept is based on this.

I would really have prefered to see or design a seperate table for all the values stored in this field with an added possibility to have some dynamic information in the new table.

Lets say a table amember_subscriptions could be designed.

Then each plugin creates its own entries in that table. Everything becomes easier, visible, easy to handle etc.

Here there is a huge bottle neck develop due to this field desgin. It not only creates nightmares in the import but also makes it supposedly the entire amember slow. This field always needs to be accessed for all reasons at all times. Thats the reason why I think it could be made it better in furture versions.

At least if there is a small improvement of a new subscription table with basic data that would also help the speed of aMember.

Hallo Alex!

This field is like a hidden cave storing very important information!

I have not seen one convincing reason to have this data_status field.

I just figured out that the connection of the entire database i.e. amember & integrated database _DOES_NOT_ work if this field is not populated with extra things it needs to function.

Here is the following condition:

- There is a registered member, paid and active
- There is a subscription in the table, which I imported and added manuelly (not through the aMember_add)

Then aMember does not even know if this member in the integrated database exists!

What is the reason of having a binary field, which only gives nightmares, that needs extra processor power to calculate things and find them out?

I do not even know how to get those data i.e. necessary entries in this field as this is certainly not an easy task! I need such a system as I would be constantly importing users into amembers sidetracking the system of rebuild.

Hallo Alex!

The only thing rebuild.php does is to feed details of subscriptions into this field $member['data']['status']. If this field is empty or not updated or incorrect, the entire amember installation will not function correctly for understandable and logical reasons, the manner in which the scripts are programmed.

To clear misunderstandings, I _DO_NOT_ criticise the programming. The scripts functions very very well and excellent and I love it. However, they will not work in certains or specific conditions that are not programmed for in certain situations like I am facing.

Well, after looking at many areas of some scripts that are related to the function of rebuild, etc. I thought of following suggestion:

1. Offer a new amember_status_table where all the necessary information could be stored rather than a binary field.
2. Offer Rebuild in parts rather than the entire database with all databases integration.

It would be the best to offer a possibility of rebuilding the site with some condition based on the following possibility:

Rebuild based on > after certain date
Rebuild based on > a particular subscription or product / products
Rebuild based on > from a number of member_id upwards for e.g. from member_id = 3000+, etc
Rebuild based on > payment system

By passing those values to rebuild, the database _NOT_ blow out the site and server power, which is now the case.

In my case, the rebuild takes 6 hours minimum!

Adding 10 - 50 new members manually, I cannot afford to rebuild the entire databases with plugin integrations. Further, if I add one more database that amember needs to manage, it will bring down the site while rebuilds.

During the rebuild all the plugin functions are deactivated, if I understood correctly. So by adding 10 - 50 members, the site will need to be permantly closed...

Hallo Alex!

Very dangerous if the products are not in the table registered because the function plugin_subscription_deleted will delete it!

This did happen and I fortunately had a backup, which was not easy to rebuild or reconstruct!!!