Oddly enough, the search function works. :)

I'll save you a few keystrokes:
https://xoops.org/modules/news/article.php?storyid=1549

I have done this on my site. Three different groups each get their own news even though they all visit the same main page. You just need to set up the permissions accordingly. It takes a little foresight to establish appropriate groups, but once you have your userbase divided into their groups it's easy. Especially since you can add the same user to multiple groups if you wish.

Only admins post news on my site. I haven't looked into allowing users post news themselves. I'd imagine it wouldn't be a problem.

I do the same for my forums. Each group sees only that which they are supposed to.

In case it makes a difference, I use the 2.2.x version of Xoops.

Which SPECIFIC features would you like to see implemented in CBB?

How would your rank them in order of importance?

Why are those necessary?

Those seem to be good questions to ask yourself when requesting features rather than "I want everything X has and more". Be reasonable. Pitch your suggestion nicely. Offer to help. This last part is important as every XOOPS module has a very small staff (usually a single person) working on developing, documenting and testing.

Quote:
Very good point and I agree with you for the most part. Automating suspensions is a good thing. But you really don't need to see 9000 log entries unless you want to; you just need to see a filtered subset of those log entries. And unless you suspect a problem or you're doing a periodic security audit, you probably don't need to view any log entries.

Add this to my list of feature requests: when displaying security information, XOOPS admins need to be able to define the time period shown. Since last view, last day, last week, last month, last six months, last year and view full log sound like they'd cover most admin's needs.

Xoops is used on some very large sites and trying to monitor security at the level I am asking on a daily basis would be prohibitively time consuming. However, XOOPS sites are attacked at times. Being able to easily access this information could be invaluable; much like turning on PHP debugging is useful for tracking down coding errors. Sometimes, you just need to spend the time sifting through the information to fix the problem -- but we need access to the information in order to do so.

I am not a coder so I'm likely just being naive, but I can't imagine a security block could slow things down on a site. The data is already being collected and logged (I hope!). I am simply requesting a means to actually display it from within XOOPS in a user-friendly format. Additionally, it would likely only be displayed to an extremely small subset of the site -- likely just the admins.

Thank you for considering my suggestions.

Quote:

Just a quick note. This feature being "protested" prevents social hacking, not brute force dictionary attacks. They are very different. In many forums, it's fairly simple to get an idea what some users may have for a password based on what they write about. Someone that likes cats a lot and has one named Fluffy has a decent chance of using Fluffy, fluffy1, myfluffy, or something similiar as their password. Spouse names, children, pets, hobbies -- baaaaaaad passwords.

Social hacking is much more of a problem than brute force hacking. If the hacker has access to the database, it's game over anyways.

I'd like this feature to remain part of Xoops, please. What I don't like is that this new feature does nothing to protect older users.... Great for new installs but of somewhat less limited use for established sites.

I'd like to see a notification go to the admin when someone misses their password 'x' many times.

I'd like the option to prevent users from changing their name. This should be the default.

I'd like the option to turn it off. XOOPS should make both usernames the same automatically in this case. That way you can change your mind later.

I'd REALLY, really, really like a block that shows all questionable information like failed login attempts, simultaneous logins, maybe even logins outside of the user's normal login times. Add in the standard SQL injection detection and other niceties from the Protector module. It should include IP and the option to ban. Distribute it with the core. XOOPS needs some form of intrusion detection reporting and logging. This sounds like a good place to start.

I've been using one of the old backup modules in XOOPS 2.2.x without any problems. I manually run it bi-weekly on my very small site and have it email the file to a gmail account I set up so I can have an offsite backup. I zip up the whole directory structure quarterly or before any major updates.

Goober's suggestion sounds much better. It would be fantastic if a mod author would adapt that to XOOPS and automate it. Reliable backups are one of the most important things to have for a website but for some bizarre reason, they are treated as an afterthought....

If I were to rank the must-have modules for a XOOPS site, they'd be news, forums and backup. Everything else can be added to suit the needs of the site. We've got excellent choices for the first two. Now if only we had a feature-rich backup....

There is not a straight conversion.

I know you don't want to hear this, but the best way would be to make a test install of XOOPS and print out the database tables. Compare them to your existing website database. Make adjustments as needed and insert the old data into the new database structure. It's tedious. It will take some time. Not every single field will match and you may lose some data because the two programs are different.

I moved my website over from phpNuke a few years ago. At that time, I had no knowledge of mySQL. Reconstructing a database from scratch was quite frankly a scary proposition. I learned a lot. I made some mistakes. It took me more than one attempt. In the end, the only real hard part was the forums. I can't say that I really know mySQL now, but I am comfortable enough now that I will make changes to it and know that those changes will do without fear.

Good luck.

1. Admin Menu --> Preferences --> User Profiles --> General Settings --> Select activation type of newly registered users

2. Which news module and version number?

Your best bet for a quick answer on the news issue is to do a search on this site for it. This has been reported before as an issue in one of the news modules and I think it was corrected. Search is your friend.

Quote:
Comparing XOOPS to other projects is definitely useful as that is what consumers and corporations will do. They have a set of criteria that they want to have met. They check the products that are available. They make decisions based on whether their criteria will be met to their satisfaction. This seems to be a rather no-brainer. While we don't need to follow other's trends, we do need to be aware of what they are doing and make sure that we know what criteria we are aiming to meet.

However, that isn't why I posted the topic. To be quite honest, I am much more interested in the politics and sociology of forking projects. This is a good opportunity to look at what they did or didn't do and to try to understand what we can learn. What caused their break? What has caused our breaks? What is gained and/or lost by forking? Who does forking affect? Is forking good or bad and to whom? Does forking affect productivity? Does it aid innovation? How has forking affected Xoops?

I'm also interested in the aftermath of forkings. I'm curious how people make a choice as to which fork to follow when there is often not much real information generally available to the public. If the new projects have drastically divergent goals, it seems to be easier to make a choice. But what if they remain very similar, perhaps striving to maintain interoperability? How do developers make their choices and are they different from those made by end-users? How has forking affected Xoops?

Quote:
Thank you jmorris for your succinct summary of how to make changes. I have worked with and been lead administrator on a number of open source projects. What you recommend is what every project I've been with desires. In short, a little mutual respect and proactive cooperation go a long way to making a community more productive and more enjoyable.

As an aside, I find LB and his troll friends to be interesting; sometimes even a mildly amusing. They have given up on XOOPS as a failure -- every step taken is in the wrong direction; communication is non-existant; the bug fixes and changes are never the right ones, aren't enough and are too late. They demand that decisions be immediate and decisive but democratic and all-pleasing. They have an incredible obsessive NEED to post their opinions -- repeatedly -- about a product they feel is horribly misguided. Absolutely amazing.... Gotta love the internet....

For those of us that haven't really been following along with the news of the recent Mambo - Joomla! forking episode where their entire dev team and most mod devs left Mambo, here is a quick overview as posted to slashdot.org this morning.

Of note, while the author of the article posted it to slashdot anonymously his email points to an admin at Mambo's site.

Original site of article

What I found most interesting was the slightly divergent goals presented at the end of the article. Can we learn anything from their experiences? From their new directions?

*** Edited to remove google cache link due. It won't link properly due to spaces. ***