I have a custom php script (that was created by a friend who is no longer available to me) on my 2.2.4 site. It is used to allow members of a certain group to download a list of member names, addresses, etc., using information from the XOOPS db, including the tables shown in this code snippet:



I need to update the script to work with 2.3.3 where the table structure in the db, particularly for the Profile module, has changed. Unfortunately I'm not a programmer so can't do this myself.

If someone can help I can provide the full script. The snippet above is included just to show what tables were being accessed.

I am willing to pay for this service.

Barry Cooper

You have to install the profile module and create the used profile fields: member_id,lastname,firstname,addr1,addr2,city,state,zip,country,home_phone,work_phone
In your SQL query the user_profile table is now called profile_profile. I doubt the memberid field, I think it could be left out of the custom profile vars by replacing it with profileid.

Yes, I do have the Profile module installed and upgraded from the 2.2.4 version. The member_id field is a custom field. I also had realized that the user_profile field had become profile_profile. I had tried that and got a mySQL error, which just showed what the query was. I initially thought this error was due to the changes in table structure in 2.2.3. Some of the fields in the old user_profile have been moved to users.

As I was studying these changes in fields I suddenly saw the critical change. The field profileid in the old user_profile table is now called profile_id in the new table profile_profile. Once I made that change in my php script, it works.

Thank you for your comments. They helped by focusing me on the exact field names in the two database versions.

My last "complaint" now is that the default date fields in the Profile module cannot be made non-searchable. In my installation that breaks the search (using search.php). I'd be satisfied if I could use a null value in those fields (last login, regdate) rather than the current default values. Do you know if that could be done?

Thanks again,

Barry

Seems a bug.
Are you saying leaving these date fields empty was not a problem in 2.2.4?

The problems I have with the date fields in Profile in XOOPS 2.3.3 feel like bugs to me. I have posted about this before. You suggested that it might be the same bug as you refer to in this current thread. I don't think it is. As you can see from my original post, I have run into a few problems. On my live site (http://www.aka.org/aka/) you can make the XOOPS default date fields non-searchable so that they don't appear on the search form. To see this you would have to register and choose the link to Find Members under The Members in the left panel). As admin, I can see the date fields, but they contain a null value (YYYY/MM/DD). If you click on the calendar icon, it pops up and you can select a date. If you go to my 2.3.3 site (still working on it) at http://www.aka.org/aka23/ you will see that the date fields are auto-populated with a date. If you click on the calendar icon you cannot choose a date. Notice that the icons for the other fields show through the calendar pop-up. That seems to indicate that the calendar pop-up is not "in front" and thus can't react to clicking on a date. At the moment you can see the date fields for searching even without logging in as I can't make them non-searchable. If I try to do so, the search.php funtion doesn't work.

Again, I am willing to give temporary admin access if you wish to look more closely.

Thanks,

Barry

For the calender add a z-index:100; or something to the calendar div in your css file.

Thank you. The worked. I had to do a little guessing about which css file you meant but I figured out it was calendar-blue.css. The calendars now work.

Do you have any thoughts on the other issues I mentioned?

As always I appreciate your willingness to help us non-programmers. I learn by doing these things. Some day I will find time to learn more about simple programming in PHP, css, etc. In the meantime, I'm glad you guys are there.

Barry

I have done a little more experimenting with this problem. These are my observations:

1. I can make both of my custom date fields non-searchable and the search.php function still works.

2. I can make EITHER of the XOOPS default date fields (reg_date or last_login date) non-searchable and the search works.

3. I cannot make BOTH of the XOOPS default date fields non-searchable. If I do, the search function no longer works.

I have made a quick web page to show the results. You can see it at this page

I think this must be a bug.

With error reporting turned on I get the following when both of the XOOPS default date fields are set to not searchable. These errors do not appear when at least one of those fields is set to searchable.

Notice: Undefined index: uid in file /modules/profile/class/profile.php line 330
Notice: Undefined index: uid in file /modules/profile/class/profile.php line 331
Notice: Undefined index: uid in file /modules/profile/class/profile.php line 330
Notice: Undefined index: uid in file /modules/profile/class/profile.php line 331
Notice: Undefined index: uid in file /modules/profile/class/profile.php line 330
Notice: Undefined index: uid in file /modules/profile/class/profile.php line 331
Notice: Undefined index: uid in file /modules/profile/class/profile.php line 330
Notice: Undefined index: uid in file /modules/profile/class/profile.php line 331
Notice: Undefined index: uid in file /modules/profile/class/profile.php line 330
Notice: Undefined index: uid in file /modules/profile/class/profile.php line 331

Barry

This is only the case for XOOPS 2.3.3?

Yes, in 2.2.4 you can make all date fields non-searchable. That is the way my current live site (which I'm working on updating) is set up. Non-admins, including guests, can not search the date fields. You can see this at http://www.aka.org/aka/ under The Members/Find members. It produces the correct search result (search for Last Name Cooper, for example).

Another issue in Profile under 2.3.3 is that when one clicks on one of the found members in a search result, the details come up in a very strange order. They do not respect the order set up in the Profile fields admin pages. The search form does, the the details for a particular found name do not. It would be very nice to get that fixed.

Barry