Client wants to start allowing members to register with their email address in place of the username. I have checked to see if an email is accepted in the username field when registering and there doesn't seem to be a problem. Will there be any issues with using an email address to login with instead of a username?

Using highly customized version of XOOPS 2.2.4 (upgrading at this time is currently on hold).

Thanks,
Hope

No need for a hack. I switched to using the recent posts block instead.

Hi Mamba,

Sorry, I probably should have explained that the posts are for SEO purposes, so I do want search engines to access and for the posts to be seen in the search engine results. I just don't want them to be too obvious in the lists. In hindsight, I should have made these posts when I first opened the topic but didn't think about it until now. I realize they will move down the list eventually but was hoping to speed up the process manually. Any thoughts on an if statement somewhere in the php block code or the block template to exclude those two posts?

Great idea for a different situation though!

Thanks,
Hope

I wonder if it's possible to hack the code for CBB Recent Topics block. The issue is that there are two posts that I want to exclude from the list of posts in this block. I changed the post date in the database so that they are much older than other posts. This worked for appearing last in the actual forum topic list but the block is still listing these two topics first even though I have set the block to show only most recent. I assume the block must be going by the p.post_id or topic id instead of post time?

Or is there a place in the database to edit the block to exclude these two topics either by changing the post time or post id so that they will not appear at all in the recent topic list? I am using CBB 3.05.

Or maybe I can use an if statement to exclude those two topics in the newbb_block.php file?

Thanks,
Hope

I'm not sure if this will help you as I am on a different version but I had the same issue and my database guy discovered that the data was missing in the groups_users_link table. Once that was restored from a backup, I was able to login successfully.

Hope

I experimented with the 2.5 alpha version today (so nice!) and in the past with one of the 2.3 versions. I notice the profile module in 2.5 does not have the same permissions such as viewing profile fields for the anonymous group. In 2.2.4 it is known as "Field visible on profile for these groups". I don't remember what the 2.3 version offered but I assume it's the same. Can this be hard coded in somehow? I have a site for an organization that requires specific profile fields hidden from anonymous and it doesn't appear we can do that any longer. Perhaps I've missed it and the setting is somewhere else in the admin? If not, I can't understand why this option wasn't included nor how the 2.2.4 version can be upgraded and keep the same permissions.

If the "Field visible on profile for these groups" option for anonymous has been permanently removed, what is the suggested substitute for extended profiles? Currently, the profiles module is perfect for our needs in 2.2.4., easy to use, displays to correct groups, etc. This is so disappointing...

Thanks,
Hope

Thank you for your help ghia!
================

Edited reply to note - your suggestion worked! The avatar issue is solved.

My other issues are what was found in the table check module: problems with 3 users data and something about group perm id but I'm not sure how to deal with it yet or how to explain it.

Until then, thanks again for your help.

Hope

Hello,
I use both backpack and backup modules to backup. All seemed to be running well until I tried to backup yesterday. Here is what I get when trying to backup with the backup module:
SHOW FIELDS FROM databasename.tableprefix_avatarTable './databasename/tableprefix_avatar' is marked as crashed and last (automatic?) repair failed

I know very little about databases or how to repair tables. I did go into phpMyAdmin but I don't know how to repair and the message in phpMyAdmin when viewing the avatar table is:
Error
SQL query: Documentation
SELECT *
FROM `tableprefix_avatar`
LIMIT 0 , 30
MySQL said: Documentation
#144 - Table './databasename/tableprefix_avatar' is marked as crashed and last (automatic?) repair failed

I have a recent backup and it shows all the dumping data and table structure for the avatar table. Is there a way for me to fix or restore the avatar table? The backup is not recent enough to use in other areas so I wouldn't want to restore with the entire backup - just the problem table.

The avatar table is the most important issue (I think) at the moment but I have found other issues as well such as a partial registration with no user profile. So the only thing in the database is the user but not their profile info. When I try to pull up the user ID in XOOPS admin, there is no info, as if the user does not exist. The good news is there has been a successful registration since then but I still have that incomplete user in the database and will need to know how to delete without issue.

There are other issues showing when I ran the TableCheck module. I suspect it has to do with either a recent server move and/or deletion of a large amount of users from the database.

I am running a XOOPS 2.2.4 site. Unfortunately, I cannot upgrade at this time but would like to in the future.
PHP version 5.2.10, MySQL version 5.0.67

I hope someone can help me soon as I cannot backup properly and fear the issues will get worse if I put it off much longer.

Thanks,
Hope

My apologies. I'm still a little lost on this one.

According to a previous post, before the exploit could take place I would need to:
1. be logged in to the site as admin
2. click on an evil link sent to me in email

Is the above correct? If so, just for the sake of asking, how would said evil person get my email address? The XOOPS site I manage is a paid membership site and not open to just anyone so any member emailing me directly would be a trusted source. Regardless, my email address is not public, only a contact form is available.

If the above is not correct, please help me understand. This all seems a bit complex for me.

Last question - does this exploit include all versions or only 1.63? What about prior versions?

Thanks,

Hope

Sorry. I'm still confused. Can this 'exploit' be done without my help as the admin clicking on someone's link? In other words, can a hacker submit news articles from my XOOPS site if they do not have permission?