Looks to me like the template article_index.html didn't make it into the database when you upgraded, or for some reason it disappeared from there. I think the names of the templates changed in one of the last versions.

Can you have a look whether you have /modules/article/templates/article_index.html? If you don't, you shoud probably download the entire article module anew and reup it to your site. There might be other files missing. If you do, perhaps going into the backend to the modules management, and upgrading the article module one more time could do the trick.

If that's not the problem, it might be helpful if you indicate from which version you've been trying to upgrade.

Maybe you're sending through smtp? Or your webhost uses your registered email if you use sendmail? Perhaps you can experiment a little with the sending method in system settings --> mail? Please don't forget that there was an issue with sendmail lately.

This is just a very rough guess, please disregard if you were there already.

The form gets populated in /modules/article/include/form.article.php and written by /class/xoopsformloader.php. That's pretty much standard in all the modules across XOOPS as far as I can see. If you want to amend it, I think it's easiest if you stick with the objects, functions and methods defined in xoopsformloader.php. If you dig into that one, you might find a template for some body.onload javascript firework or whatever you're up to, but it might be difficult to target the precise form you want to target.

Anybody? I quite urgently need a solution for that for some functionality which is quite important on my site.

I think it's a bug in the article module. But I can't quite pinpoint it. Last version of CBB doesn't produce the same effect, so the various textsanitizers in the core and phppp's Frameworks seem to not be responsible for it.

To restate: In the article module, with html enabled in the submit and edit form, "name" attributes get stripped from html tags. That's independent of the editor I use, and it seems to be only about the "name" attribute. Webmaster can submit an html tag with a "name" attribute.

Perhaps somebody wants to run a quick test on their system and see whether it's reproducible. I get it on two different setups. Both are with PHP5 and XOOPS 2.2

Thanks!

Now this is a very long shot, but it's so weird a situation that hopefully someone will be able to give me a lead where to start looking.

If I edit an article in the Article module (version 1.0 I believe it is, the newest in any case), and insert an html tag with a "name" attribute, the "name" attribute gets stripped (including the assigned string) and the rest of the tag remains intact. This happens only on "save" and not on "preview," and it does not happen when I'm the site administrator. Only for the rank and file.

Example:

As far as I can see, this is only about the "name" attribute:

Example2:

and it is not only about the < a >< / a > tag. It also happens independent of any particular editor, but not in at least some other modules.

So my guess is that there's some text sanitizing going on somewhere. If somebody could give me a lead, I would be very thankful.

I'm using XOOPS 2.2 branch

You should wait for a day at least before you start complaining.

If you give us a link to your site, we can see whether we get your google tracking cookie (or whether we're correctly blocking it ). Plus, you get an incoming link.

You can also see it by yourself, if you list your cookies in your browser. You should have that ugly urchin uawhatnowi thing listed under the cookies for your site if google analytics is picking it up.

Yeah, that's shady. The iframe loads another iframe which is here: 81.95.145.240/go.php?sid=1. I don't know what's that, it comes back empty when I try to fetch it. It's not in your theme.html, and it also doesn't seem to be coming with your modules. So, you may want to empty all your cache and templates_c folder (drop an empty index.html into them once they're empty, just in case), and also make sure your index.php in the root directory hasn't been altered.

*edit: New info*

Yes, it's definitely the iframe, and it's definitely nasty stuff being triggered there. Read here:

http://isc.sans.org/diary.html?storyid=2923
I find it probable that someone has hacked your index.php at your XOOPS root. You should try to get your webhost to grep your entire directory structure for the string "iframe" and see whether all of them are accountable for. Or perhaps the malicious IP will do for a search string. Perhaps you have shell access and can do it yourself.

Furthermore, I think it's likely that someone has hacked your server, and not your XOOPS installation. You may want to alert the server admin.

Thanks for the hint. Phppp has also published a security alert some days back. It's athttps://xoops.org/modules/news/article.php?storyid=3799

Quote:
That's my understanding. I believe it is a vulnerability in an old version of the Spaw editor which exists with those modules/scripts that make use of its class. My wiwimod doesn't, probably because it never did. But perhaps, I've also kicked out Spaw, because I had other wysiwyg editors.

In any case, I don't know what happens at those sites where the wiwimod version with the spaw editor has been simply upgraded, without removing the spaw files, so that, even though the spaw stuff isn't used by wiwimod anymore, it's still there and waiting to be attacked. One would hope it aborts, because of errors and root path and stuff, but who knows?

Which is why I would recommend everyone has a look into their installation and see whether they have the spaw stuff in there. In case they do, it might be wise to take precautions. I think that just deleting the directory root/modules/wiwimod/spaw should do here.

That's a remote file inclusion vulnerability, and it seems to be really ridiculously easy to exploit. You just pass a path to your own script in the url query string, and that stupid spaw script parses your own malicious script and includes it in its own flow. Something like that. It does you the favor to parse your own script, figure that!

Apparently, the vulnerable spaw has also been used in XT Conteudo (see last comment), and who knows where else. I, in any case, have grep'd all my installation for all vestiges of spaw.

Ok, thanks. That's what I figured. The script they want to run is quite obviously about getting a shell from the server. So I think I better don't try it. Might get me in deep #OOPS# with my webhost, hehehe.

In any case: Watch out everyone with Wiwimod and a directory called "spaw" inside the wiwimod directory. Even if it's an old exploit, it looks like it's been revived by someone. So there's some activity on that count.