Sorry to hear that. I figured out it was the permissions on the cache folder that was causing my problem.

Did you find a solution to this? I didn't upgrade but deleted the profilefields temp file in the cache directory and now I'm getting the same error messages.

See above - mystery solved.

Something has happened and I don't understand what it is. Some registration fields that are required are letting users complete registration with the fields left empty. Is there some way I can check this other than what I've already done?

------------------------------------------
UPDATE:
After much eye strain - I finally figured it out. One field was causing the problem. I'm not exactly sure what it is, but I think it has something to do with no default being selected on that field. It was above the other fields (order-wise) and caused any fields placed below it to not force the user to complete the field. So glad the mystery is solved!

C

You might want to suggest to your users that they not save the login information in their computer (if they have the password manager feature enabled) or they might get confused the next time they login. Just a thought...
Quote:

Nothing seemed to happen with the debug while changing the password. And the new password saved with no problem. In my original post, I meant to say optimize the database, not back up - but both procedures are very quick. I think I must have been optimizing the database at the same time as the password was requested. Perhaps that's why the changes were not written...?
Quote:

Hello all,

A registered member used the lost password feature and was sent both emails correctly. The problem was, the password was not changed in the database. It still had the old password. Here's what happened.

The member forwarded to me the original email containing the new password information after trying to log in unsuccessfully several times (silly me, I previously suggested she copy and paste the username and password into the appropriate fields). When I tried it, it didn't work for me either. Since several of these members were added manually, I tried the original password I'd used to add her with. That worked and I got in.

I checked the timestamp on the email she received the new password in and thought maybe the server had a glitch, or maybe I was backing up the data at that very moment but it doesn't look like it. Our backups last mere seconds. They're really fast because the database is not very big.

I've never had this problem. If the lost password feature doesn't work - it's usually due to the member's ISP rejecting email from the site's mail server. That I can understand. But to send out a new password and yet it remains unchanged in the database is a new one and I must say, bugged me more than a little. Has anyone had this problem and is there any way to troubleshoot it?

Thanks in advance!
C

Quote:
Yes. I did omit the script tags... but I didn't usehttp://www.mydomain.com for window location as you have done. Perhaps that's why.

Maybe adding the code to an external js will work in XOOPS but I found it did not work for me in my non CMS site. I couldn't figure out why but it only worked in the head tags.
Quote:

I don't think Google is offended if we use a frame buster on our pages. I get a lot of referrals from Google images on one site (non CMS) and use the code there for every page. What happens is the page jumps directly to my site instead of viewing part of it through Google's frame. So no harm done. It doesn't prevent Google from spidering.

That being said, I can't say for sure Google isn't offended. These days it doesn't take much to offend the Big G and the rules of G's game are always changing. Who knows if this will be a problem in the future but so far, it hasn't been. I don't think a site owner should be penalized for trying to keep his pages from being displayed on someone else's site.

Quote: