True. I guess I was thinking about something like DuGris's Captcha class (SecurityImage). Something which could administer the traffic with the Akismet server and which would potentially have an interface, to drop in keys and stuff. And which could then be called with an easy hack from the routines that validate posts and write them to the database in the different modules. They work, of course, all slightly different, so it's probably not possible to implement it centrally, without hacking each of them. Would be nifty, though, to have it in "comments."

DuGris's captchas work great, but Akismet's behind the scenes approach is just plain cool. Kiss good bye to them dirty spammers, without having to explain an extra step to your users. I'm getting considerable amounts of spam on my Wflinks. It's always required admin approval. Don't those #OOPS#s ever learn their #OOPS# just doesn't get onto my page anyway? Well, I guess it's just too cheap to submit spam.

I'm using Akismet on a Coppermine gallery, and it works great. I would love to see it for XOOPS as well, as a module or just a dirty hack.

Oops, sorry! I knew there was something I had overlooked. That's what happens when you just copy & paste. I've changed it above in my original post. Thanks by the way, DuGris, for your great work.

Quote:
Sure, the problem being that I implemented the thing before DuGris came up with his new version for PhP 5+. So I haven't tested whether it actually works this way, but I wouldn't see why not. The code to be dropped into the files is from the hack for the contact module DuGris has posted a few days back.

It's two steps: Generate the image and display it in the form, and verify the user has entered the correct code. In CBB3, at least when you're admitting quick reply, you'll have two different places at which to display security images. For quick reply, it's in viewtopic.php, for full reply in include/forumform.inc.php. Both times, you will want to put the code for the security image before the "submit" button. Verification in post.php. Makes three files to hack.

In viewtopic.php, around line 608:

In include/forumform.inc.php, around line 262:

And to check whether the user has entered the correct code, in post.php, around line 135:

There're, in fact, various parts inside post.php where I imagine the securityimage code would make sense. Depending on the order of the several verification steps to be performed. I'm not claiming that this is the most appropriate point to drop in the code, but it's working fine for me. It's here after it's established there's some content in the post at all. If anyone has a better idea or knows a reason why my method is not good, please let me know.

Oops: "tamairanslip" in the code above, I take, stands for j a v a s c r i p t : and is sanitized by this XOOPS here. Please substitute, without the spaces of course.

Dirty hack while people who know about XOOPS and php are coming up with a good solution. I know nothing about php, servers, or anything else, and my little hack may be absolutely problematic, in which case I would be grateful if someone could tell me. But it seems to be working fairly well, for all the places where dates turn up on my site and are spit out by this particular function. Talking about News module, Article module, CBB3+. The following works for me on XOOPS 2.2.4 and PHP 5+

The task: Getting day and month strings to display in languages other than English.

The problem: As far as I could see, dates in XOOPS are often formatted by formatTimestamp function in local.php inside /xoopsroot/language/, which spits them out with php "date" function, which seems to be a little parochial when it comes to producing output in all this worlds nice languages. At least at php.net, it says one should use setlocale and strftime instead to get localized output. So that's what my dirty little hack is about.

In my language/yourlanguage/local.php, at the bottom of the function formatTimestamp, there's a line:

I've replaced that line with:

The "if" thingy to give the rss feed the output it needs, and all the other parts of the site should get the localized output. The es_ES thing has, of course, to be adapted to the specific language and server set-up, this one's for Spanish at my webhost.

Now, "strftime" takes a different input for $datestring then "date", and that part I've also hardcoded into local.php, instead of changing the language parameters in global.php. To not mess up any other function which might use them. In other words, inside the same function formatTimestamp, wherever it says something like _DATESTRING, I've replaced that with the format I wanted. In case l, for instance:

That gives me something like: 10-ago-2006, 16:08:30. 'ago' being Spanish short for agosto/August. Reference here:http://www.php.net/manual/en/function.strftime.php

Case 'mysql' is probably quite sensitive, for database input. I've figured I get the same output with:

I hope I'm not mistaken, but so far, I can still post to my forums and see a decent UNIX timestamp for it in the database. Finally, I went into the preferences of the News module and also changed the date string there to something with the percent sign.

Well, I know this is pretty dirty and needs to be manually adapted to the needs of a given server. Just thought I would share my hack, and I'd be very grateful if someone told me if this idea of mine is going to bring me into a deep mess down the line.

Thanks GlaDiaC, thanks Defkon1. With the kind help of the two of you, I finally got it to work on my site as well. XOOPS 2.24 and PhP 5+.

I'm currently using it with CBB3+. Should anyone not be able to figure out where to drop the code in that module, I will happily share what I've done.

*edit*: Ok, found it myself, mods please delete this post or keep it for reference if it's worth it. The solution: There's an editor_registry.php in each of the folders of the different editors in /class/xoopseditor/. I've changed the "order" paramaters to sort them to my liking, which now seems to bring up Tinyeditor first. "Seems" because the cookies, you know. Will verify from a different machine.*end edit*

There're a lot of threads on how to change default editors here and there, yet I couldn't find an answer to my specific question...

...which is fairly straight forward: In XOOPS 2.2.4, where do I change the default editor that's picked from the ones that are present in /class/xoopseditor/ ?



The situation: I've succesfully installed Tinyeditor, and it works like a charm. I'm using it with phppp's article module, which, under XOOPS 2.2.4, lists a choice of editors from the Xoopseditor framework. Everything's absolutely and outrageously functional and nice, and I love it. Many thanks to everyone who's coded the different components.

Only problem: When people call the edit page, first thing that shows by default is the textarea editor. I would, nevertheless, pretty much prefer the Tinyeditor to load by default, with the textarea thing being used to fall back in case there's browser incompatibility. In other words: I don't want to uninstall anything or reduce choices for users, just to change the default, so that people see, if possible, a nice graphic interface instead of what, in that module and on my site, otherwise is raw html code.

Many thanks!

Quote:
Hey man, you rock!! Many thanks! Shall try it later today and report if I run into a problem! Which, of course, will not be the case.

I agree, it should be part of the core. But I understand they're working on it.

Tobias

DuGris has developed a Captcha implementation for XOOPS. It's athttp://www.dugris.info, with documentation on how to implement in several modules. It's called SecurityImage. I have my doubts it works with PhP 5+, though. On my local box, it spits out a fatal error which seems to have to do with PhP 5. Experiences very much appreciated.

Also discussed in several threads, for instance:https://xoops.org/modules/newbb/viewtopic.php?topic_id=49873&forum=20&post_id=226486#forumpost220129

I think Captcha is an excellent way to reduce spam. Forcing people to register can be quite detrimental to overall life on your site. Sorry for the visual impaired, but I have to mainly think about how to lure the computationally impaired into participating in my site.

Also: How do I actually temporarily disable the root path check function in 2.2.4?

It's set to '0' --> still gives the root path check error
It's commented out entirely --> still gives the root path check error
All of the above + the Protector pre and postcheck lines commented out --> still the same error

/cache/ and /templates_c/ flushed over and over, browser cache and everything, no proxy. ??

Plus, the installation pulls definitely on the mainfile.php I'm working on.

I don't understand a thing of what's going on here!