OK. I have just finished doing a very careful duplication of my live site, followed by the upgrade to 2.3.3. After uploading the 2.3.3 files, I ran checksum and everything was fine. I then ran the upgrade script. The upgrade went smoothly. I installed the Protector module. I updated the system, PM and Profile modules. I did not update all the other modules and did not activate all the blocks. However, I was able to access my_test_site/modules/profile/search.php. I got exactly the same result as previously. I am now convinced this is a bug. It may not show up in every installation, depending on one's setup of profiles in 2.2.4, but this is very repeatable and it has to be fixed. At least for me I simply cannot upgrade my live site until it is.

I will submit a report on the 2.3.3 bug report site but any other suggestions as to what I could do would be appreciated.

Barry Cooper

If you look the 'cole' records up with phpMyAdmin, all are still present?
What is your character set and collation for the users table?
If you put debug mode on, you could see what query is effectively done when you do the search (the one of interest will contain cole, as Trabis already pointed out).

First, I want to thank you for your help. Now:

At the moment I have two installations of 2.3.3 versions of my site, resulting from two attempts to upgrade my 2.2.4 site.

When I search using profile/search.php in one of them I get one error:

Notice: Use of undefined constant _PROFILE_MI_NEVER_LOGED_IN - assumed '_PROFILE_MI_NEVER_LOGED_IN' in file /modules/profile/class/field.php line 303

I'm not sure why I'm getting that as it is defined in profile/language/english/modinfo.php

The relevant query that I get when I turn debug on is:



Some of these I would not normally make searchable but I have everything searchable at the moment.

Interesetingly, if I run that query directly from phpmyadmin (entering the prefix value for my tables before users and profile.profile), I get the same three hits, missing the others.

Hoever, if I look, using phpadmin's search tab, for %cole% in the users table they are there (plus a couple of others with cole embedded within the user name. I can also find them all using the admin search menu in 2.3.3. It's just the profile search that's missing them. I also find the correct five hits if I search the table profile.profile using the search tab. That, of course, is where my custom fields such as first name, last name are kept.

Could it be that the profile module is generating incorrect MySQL queries? Either that or there is something wrong with some of the records in my tables?

Collation in all three databases is latin1_swedish_ci

The only difference I have found between the 2.2.4 and 2.3.3 installations is the charset stipulated in language/english/global.php (I assume that is what you are asking me). In my live 2.2.4 site it is ISO-8859-1. In the two 2.3.3 installations it is UTF-8.

BTW, server info:

Apache 2.2.11 (Linux)
PHP version 5.2.9
MySQL version 5.0.75-community-log

Still hoping for a solution.

BC

If you use the query from XOOPS (with the prefixes added) and you replace cole% by %cole%, do you find then all the records? If so, this means that some of them have a space or so in front.

You should align the character set in global.php to the character set used in your database and set it to ISO-8859-1. In mainfile.php, it should say latin.

Quote:

The answer is in front of you.
Some users renew date is far ahead like in 2038 (admin for ex).
There is no bug, just no paying atention.

And that renew_date is a user defined user profile field?

Quote:

Yes(I guess is the admin who set it or some script during registration).

It would be useful if date forms had an onchange awareness. I mean, having no default value set so they could be used has required in regstep. For this case, I do not consider it a bug.

First, let me say that I did consider that cause. To address it I eliminated all the date fields from the searchable fields. That completely breaks the seach function. I did not have enough energy left last night to test that in more detail. However, this morning I have. You are correct, if I include in the search that the renew date is 2039-12-31, I get all the hits. I had overlooked that previously because the date fields were off the bottom of my screen with all those fields searchable. This problem, incidentally, did not occur in 2.2.4 because the date fields have a null value entered by default, not a date.

However, the obvious solution was to remove those date fields from those that are searchable. As indicated above, I did so and then you get just one line of results. You can try that on my test site. This morning I tried removing fields from the searchable list incrementally. What I found is that I can remove my custom joined and renew date fields but I cannot remove the XOOPS default date fields (last login and member since).

Perhaps this is not a bug but it could be considered a design flaw. I think that many users will not want their readers to search those date fields.

The reason, incidentally, that we set some users' renew dates far into the future (i.e. that latest date that php can handle) is that our club has life members. We periodically search for members whose membership payments are due in a particular month. We don't want those life members showing up, which could cause us inadvertently to send them a renewal notice.

Disclaimer: As a programmer I make a good veterinary pathologist. In other words, I consider myself an informed user but I am no programmer.

Again, thank you for taking the time to help me. Perhaps my experience has revealed a potential issue.

Barry

My post about blank profiles for certain users and not others makes me think our problems are similar. You know what stands out to me as something we have in common, despite me coming from 2.0.15 and you from 2.2.4 we both went to UTF-8 on our DB. I think that might have something to do with it. Just a hunch, but the best I can come up with. Incidentally, I am running php5.2 and MySQL 5 on my server.

Since you are in the mood it seems to do test installs, maybe one of us could try an upgrade and not use UTF-8.

When I didn't use UTF-8 in my tests all apostrophe's came out as funky characters. Hence why I went that direction. Shame on me in those early testing phases I never specifically tested the profile, however I don't recall any odd blank pages at the time.

Ken

I just checked my server and it is set to UTF-8 charset. The server default collation is set to UTF-unicode-ci, but the individual table show collation as being latin1-swedish-ci. So, if I understand you correctly, I should leave global.php as it is (UTF-8) but put latin in mainfile.php?

Any further thoughts on the date issue. It seems to me that as the users are allowed to remove those last login and date registered fields, doing so should not break the search function. I am reluctant to hack core files, but if a fix for this will take a while, is there some way I can make those date fields default to a null value?

Barry Cooper