I've fallen in love with Ubuntu Feisty and haven't looked back into my Windows partition for a couple of weeks now. So, I can't give you step by step instructions on how to do things in IE, and it also depends on the version. In general, I don't think there should be more of a problem with XOOPS based sites than with other sites that require a login. If you have your IE security levels scaled to be able tp log on to all the other sites you log on to, the XOOPS site should normally also be operable. But then, they've taken so much blame for lax security that now, IE displays more security warnings than actual content it seems. Particularly entertaining I found the ones that come up when you go for the first time to the Windows update site and get asked whether you find Microsoft trustworthy.

I think you can always add your XOOPS site to the list of "trusted sites" in IE. That should do away with all the cookie and referer in http-header related problems. Search for "IE trusted sites" or something like that on the web if you need instructions on how to do that.

Clearing cookies: Normally, and if everything's configured correctly, that shouldn't be an issue. XOOPS session cookies expire (are automatically deleted) if you close your browser. But there might be a problem if, for some reason, there's some residual cookie left that doesn't belong. How to delete them? I think it's on page 1 of the IE settings, possibly depending on the version you're using. Next to "offline files" and what know I. You should be able to find instructions on the web.

How to tell users they're caught in a problem because of restrictive privacy settings? That might be tricky because, of course, the XOOPS security traps snap for a reason and to prevent potential abuse. So if it doesn't keep you logged on, that's actually on purpose, if sometimes not particularly helpful. Also, there can be a lot of different layers causing the issue. Firewall, browser,...

I think there's an error message that comes with those situations, something like "No valid session," or perhaps even "You don't have permission to blahblah." You might write it down (the error message you're getting, I mean), then search for the phrase in your XOOPS language files. You can use tools such as PSPad to search for a phrase in the files within an entire folder structure. Once you have found the place where the phrase is defined, you might want to amend it with something like "If you have looged in and see this message, please try relaxing your privacy settings or contact the administrator." Something like that.

If you tamper with language files, make sure you don't insert quotes anywhere, and no apostrophes if you don't know how (most of the time, html entities work). They are likely to break the language file. Also, be careful with diacritics, they might also throw errors or generate weird signs. Make a backup of the language file first, change the phrase you want to have changed, then try it out. In Xoops, you don't normally have to update any modules or anything for your changes in the language files (typically admin.php, main.php, modinfo.php, etc. in /language/yourlanguage in the xoops-root and each individual module's directory) to reflect. If you screw it up, you can use your back up copy to quickly get back to normal operations.

Phew, that's long. I hope it's not more confusing than helpful. This problem is also discussed a couple of times on the forums.

Is the site on a Mac or Pc, or are you trying to log into it from different machines?

Site doesn't keep you logged in typically happens if you have some firewall or privacy protection on your pc that strips "private headers" from your http requests. Try taking down your firewall for a second if you have one, or whatevery might be in the privacy protection business, and allow all headers and cookies if you're restricting them in your browser. Try a different browser, such as Firefox or Opera, if you're unsure about how to relax the privacy policies of the browser you're using.

In any case, if I understand you right and the site works ok if you look at it from a Mac, but not when you look at it from your PC, then your site is ok, and your PC is a little restrictive in the way it interacts with your site. Clearing browser cache and cookies is also always a good idea. Clearing the xoopsroot/cache and xoopsroot/templates_c folders on the server also sometimes works, but make sure you don't delete the index.html files in both folders (to prevent potential intruders from listing the contents of those folders).

If I didn't undersand you right and you have migrated the site itself from a Mac to a PC, then there's something wrong with the migration, or with the setup of your server on your PC. But that's a somewhat complex matter anyway.

That's scary! I'm currently protecting parts of my site with three layers: GIJoe's XoopsProtector v.3 (I've set it to discard any post with more than 2 URLs), Richard Virtue's Netquery which checks everything with Bad Behavior (well formedness of HTML requests and some other tests), plus a semantic check against Akismet (link to our discussion of it a few posts above). Incredibly enough, there're still submissions making their way through! They're, of course, pretty truncated an sometimes don't even point anywhere. All the more annoying. That's not even spam, that's just garbage.

I had actually hoped to shore things up with Captchas should it become necessary. It's a hassle for legit users, though.

On my site, url in the form description of liaise seem to get linkified by textsanitizer. Also looks to me like I can use regular XOOPS code (if that's what it's called on Xoops, the one with [ url = ... ]. I'm talking about the text field in the module's backend where you define the overall properties of the form, including description (caption). Perhaps you're referring to the individual form fields?

I think this also applies to McDonald's version 1.03c:

I do not have the slightest idea how, but someone has submitted a request for modification of one of the links in my WF-Links, and when I tried to follow the admin link to view the modification, I couldn't. So here is what I've found out:

admin/modifications.php calls function wfl_rating_system() twice (lines 74 and 121), but that function is commented out in includes/functions.php. I guess it's deprecated or something. modifications.php works if I comment out the "if" clause for $key "urlrating" the two times it occurs in modifications.php.

Now, if somebody could explain to me how to get to the place where users can submit modifications, and how I can control that possibility, I would be very grateful.

Oh yeah, sorry. I thought that was part of the general installation of DuGris's captcha thing, not of the module specific hack.

Phppp seems to be cooking some native captcha support for CBB. At least, he's included what looks like a relatively slight modification of DuGris's work in his latest Framework package. Still has to be hacked into the module, much the same way as DuGris's. I think you can get the new CBB to redirect the user to the preview page with the post filled in, instead of giving him or her a blank submission form, in case the Captcha check goes wrong. I don't quite remember where I found the instructions, but they must be somewhere around on this site.

I'm not using that with CBB, but I think it should be relatively easy to adapt the Akismet check hack we've discussed here to send your posts through Akismet. In combination with Netquery module's Bad Behavior and perhaps XOOPS Protector's new function to filter posts on the basis of the number of URLs that come sent in it, that might do the job even without Captcha.

Thanks for thanking. This is also very good in combination with the new version of the XOOPS Protector module, which lets you define the maximum number of links that can be in a POST request. Now I have: XOOPS Protector for a pre-screening, then Netquery's Bad Behavior to have a close look at the HTTP request, then Akismet to look at the post itself. That's pretty thorough, I would think. But amazingly enough, there are still posts which arrive at the Akismet check.

Ok, this should be a good place to put the entire comment submission routine through Akismet. Again, there're some elements that have to be adapted manually to individual server setups, this seems to be working for the XOOPS version I'm working with (2.2 branch), and I do not know about others. Also, this kills everything Akismet identifies as Spam without further notice. You can send yourself an email without much fuzz, but that's what we're all looking for, isn't it? A little more spam in our email accounts. So not for the faint at heart, and not if your users might hate you for false positives.

You need the Akismet class, API key, and so forth, as per a post above in this thread.

Open /include/comment_post.php in an editor. Depending on your XOOPS version you might find a line

case "post":

somewhere around line 140. Insert the call to the Akismet class immediately following that line. Provided that you're using the version I'm using at the time of writing of the Akismet class for PHP5, it should then look something like this:

The gray bits are from the original script, the red ones the parts you'll have to look into. I've caught a little spam in my sandbox with this, but have not brought it online. I am not saying it works. It's just a suggestion to try out.

*edit: There was a little quirk in my code quote above (a $ lacking in the declaration of $MyBlogURL). I've edited it. There might be others.*

I pretty much assume that AMS uses the comment functionality of the core to handle comments. That's what all the other modules seem to be doing anyway. And I do think we should be able to figure out how to hack the core.

If somebody can jump in and give us a lead where to hack... I've had a very brief look and didn't find the obvious place, but I will try to look, perhaps over the weekend. But I'm also not a programmer and don't know a lot about the internals of XOOPS, so if somebody can come up with a quick and authoritative answer, that would be excellent.

The question, again, is: Where in the code does XOOPS (or its different versions) write comments to the DB?

Glad you think it's useful. It really is an encouragement to experiment with it, rather than an instruction on how to use it. If you, or someone else, figures out a way to use it with this or that module, or perhaps particularly with the global xoops's comment feature, please don't forget to post back.

I'm catching all my spam on wf-links so far. Netquery/Bad Behavior did a good job until quite recently. But then, it seems they figured out a way to break through Bad Behavior, at least with lax settings. So Akismet is now doing the cleaning up.