Here are some thoughts on using custom tables, queries, and PHP to create reports. You are only limited by your own creativity and technical knowledge. I selected aMember for my national dog breed club as our membership system. One of the things I liked about it was that it ran on PHP and MySQL. If you know anything about databases, SQL, and programming, it is fairly easy to create custom reports. My club's website displays several contact lists (e.g. committees, officers, breed experts, etc.). In addition, we have an online membership roster that only members can view. Many clubs just create a webpage and hard-code some names, phone #'s etc. Then change it after elections. I didn't want to do that because we have this great membership system (aMember), and we should be using it's database to track and display committees/officers -- as well as the terms served. First I created several products in aMember (one for each officer, committee, etc.). There are no fees attached to these. Also, they are configured to never be visible to anyone -- except a system admin. When someone is elected to an officer or committee, the admin adds a "payment" for the appropriate product. When their term is up, update the expiration date (if the last day was not set in advance). Now we have a record for each office, term, and who held it. We are building history and can even can add to it for past officers (before we had the info online). To further automate reports and to keep coding to a minimum, I created several tables in the aMember database that contain only the products that apply to membership, committees, officers, etc. In addition to the product ID, several fields act as sorting options and processing "flags". I think of these tables as report configuration tables. They have no impact on anything aMember does. It is IMPORTANT to note that I did NOT customize or change any of the aMember tables. Doing so can cause problems, even if you are very careful. So, each table is named with a prefix different from the aMember tables. It keeps them grouped together while viewing (using a tool like phpMyAdmin), and they should not be affected by upgrades (hopefully). Next, I created a series of queries linking product IDs in the "report" tables to "active" payment records, then against contact information from the amember_members table. Each query was saved as a "view" and built on the previous query/view. Finally, I wrote some PHP to "present" the data. By creating views, I can easily issue a query such as, "SELECT * from report_active_mbrs". So a couple hours of work and I have an online membership roster that only current members (those with a valid aMember payment) can view. The list is always current - as long as payments are maintained (some members pay their dues by check and a payment record has to be manually added). Using the approach to create "custom" tables and views (vs. 1 big query designed for 1 purpose), you can easily mix and match for future needs. The following link will take you to a simple list of our officers and committee chairs. Data is pulled directly from aMember using PHP and MySQL. http://www.ihcus.org/contacts/main-contact We also use Wordpress with the aMember plugin. When a member logs in, any office they hold, or committee they serve is listed. An unexpected, but nice by-product.
This is wonderful! I'm not proficient in PHP or MySQL, but I would love to setup custom tables and run queries against them. Any suggestion of where to start to teach myself how to do this? Thanks! renee
I know this post is pretty old, but to learn PHP I would try Code Academy. http://www.codecademy.com/
You can also google and get a lot of examples. http://www.php.net has all the functions and language elements. If you know C, Basic, Pascal, etc., PHP is no big deal.