I don't have a solution, but I would like to second this question. I had this issue in several modules, wiwimod among them, and also SmartFAQ. I believe it's probably somewhere in the editors? Or perhaps it's some anti email harvesting feature? A mailto link in a href tag does also not prevent the period from showing up.

Don't you think it might be advisable to use a PHP version released as stable? 5.0.5? A bit of a security issue, I would say. Also, I hope you're not saying that you've chmod'd everything to 777 (write access for all the hackers out there). That's just for the very few select directories where it's absolutely necessary.

Myalbum works flawless for me. Can you specify what's the problem?

Also sqmail or TropicalMail (both in repository). TropicalMail installed quite neatly, but I don't know about the signing up feature you'd also been asking about.

I have to say, though, I ended up not liking the integration into XOOPS. Gets tight on the screen, with the menues and other items you may have configured to show on all user pages. So, I ended up firing up an independent installation of squirrelmail in a fresh window which, I think, is also better supported than the ports and what know I you may have as XOOPS modules. May be an issue, particularly when it comes to email. Sorry all hardcore XOOPSers.

My thought on the issue is that that DHTML thing isn't quite ready for prime time: Depending on your browser, they turn up all over the place, and in all different shapes.

I guess what I've been trying to say in my last post is simply that you'd probably have to change something in the theme you're using, not in the template. So, the task would be to track down the style which is assigned to the menu. The template, I assume, is somehow wrapped into the corresponding PHP script (in the "blocks" subdirectory) which is wrapped into the theme.html of your theme which calls on style.css, styleNN.css, styleMAC.css, depending on what OS and browser you're using. If you get the bullets, and the lines break where they shouldn't, I assume that's a sign of a style not being defined, or not being defined properly, in your themes css's.

I'm not using the DHTML menu, but I've quickly produced one under default theme, and it looks alright. Perhaps you can compare your themes css with the ones from default theme and see where the relevant difference might be. Also have a look into the source of the page once it's produced by the PHP engine (Ctrl+U in Firefox) and check whether you can see what class is assigned to the element that doesn't look good. To get a sense of what you're looking for in your style sheets. Bare in mind that you may have various .css files for different browsers.

Don't know whether that helps

Oh, yes. And the linebreak may have to do with your menu items being too long? Can you try with very short menu items?

jfmoore: I believe how "ul" is displayed (normally bullets) is left to the browser, unless, of course, browser settings are overridden with a style. It seems the style instructions in this particular template are mostly commented out, so you may have to look somewhere else. Somewhere in your theme, I would assume. You might try to comment out or delete the "font-size" line in the IE section, if only to see whether that does any good. But again, doesn't think this is the right place. Perhaps, you can try experimenting with different themes, and if you've found a nice one, see how the relevant class is defined in it ("blocks").

defwind: Once you add content, the drop down should get populated, and you can link new content to any of the pages you already have. Is that what you mean? I also think "Main Menu" here is not the XOOPS Main Menu, but the module's main menu, so to speak. In the XOOPS Main Menu, you will have "Content" (or something else if you have changed the module's name), taking you to the module start page you've defined, and then all your visible content as submenues to "content". If you want to have some menu structure outside of the XOOPS Main Menu, you would probably have to create a custom block (in blocks), or use one of the modules that let you costumize menues.

But, with a computer connected on a stable IP (for instance through a router; such an IP would typically start with 192...), it seems to work if the computer's IP is entered as the XOOPS URL and then exempted from cookie control in Zonealarm Privacy. Instead of "localhost", again. It's a little wacky, though, with the router having to reflect back your requests to your own machine. Also means you can't view your site if you're not connected to the router. But I've browsed the forums at ZoneLabs, and that seems to be the only solution people have come up with.

Don't think this is a prime time solution worthy of going into FAQs?

Hehehe, that was a little premature it seems. That trick made perfect sense to me, unfortunately that darn ZoneAlarm is still blocking cookies. Which is probably because they come from Apache and the PHP engine, so there might be something to be set in their configuration files.

In any case, once the cookie is set, my tweak lets me bring up the firewall again and navigate my local XOOPS site ... until the cookie expires, that is. Perhaps, someone can take it from here if there's interest...

Now for today's question: Has anyone ever figured out how to configure Zonealarm Pro to be able to stay logged into a XOOPS installation on localhost? We supposedly use the local installation to test the stuff we're not so sure about, and it would be nice to not always have to bring the firewall down while doing that.

Edit: I think I found a solution myself. Replacing 127.0.0.1 for localhost in the XOOPS URL (in mainfile.php), and then defining an entry in ZoneAlarm privacy settings allowing cookies and headers from 127.0.0.1 seems to be doing the job. ZoneAlarm privacy settings wouldn't accept an entry for "localhost", which comes with the XOOPS URL if not changed in the XOOPS settings.

Anyone? Particularly the printing problem is something that surprises me a little. I go to the Chinese XOOPS site which, I understand, is somehow involved in the development of the CBB module and get what looks to me like the exact same issue: When trying to print from the drop down menu with the "Topic options", the only thing I get is "You don't have the right to view this topic" on a white page.

Printing through the new "transfer" interface works like a charm, just the old method doesn't do it anymore. I've set almost all permissions there are, with the exception of attachments and stuff.

Now, my browser's not good in displaying Chinese, and if it were, that would unfortunately not be too much of a help either. Otherwise I could ask there. So, any help appreciated.

Just upgraded to cbb 2.30 under XOOPS 2.2.3 and getting this one when trying to post:

Quote:

Also, at least for anonymous users, the name/email isn't remembered when previewing. Same problem? Known issues? My configuration problems?

In any case, it seems anonymous users are forced to enter some name or email? Can that be changed?

Then, I get some "no permission" message when trying to print a topic, even when logged in as admin.

Finally, how do I change the date/time format?

Thanks a lot!

Ahh, feel free to post a test message on one of my forums if those problems are somehow interesting.