Xoops 2.x uses several functions, variables, etc. which are only available since PHP 4.1+. Most are available in 4.0.6+. With PHP 3.x you will definitely run into problems with missing functions, probably missing globals, and likely incorrect function calls (different numbers of arguments etc.). You might also run into trouble with the MySQL version, depending on which version you have available to you.

I was not around during the development of XOOPS 1.x but I believe you will run into the same problems there.

Have a look at this thread:

https://xoops.org/modules/newbb/viewtopic.php?topic_id=13178&forum=20

and see if it solves your problem...

Specify the top level that *you* have access to. e.g. It might by /home/users/xyz/www or something like that.

Quote:

I wonder if this is caused by the problem described here:

https://xoops.org/modules/newbb/viewtopic.php?topic_id=11407&forum=19

In previous versions of Xoops, the fantastico installer seems to have incorrectly generated a few of the config options which causes them to be unchangable.

Check this thread:

https://xoops.org/modules/newbb/viewtopic.php?topic_id=11407&forum=19

Maybe you're having the same problem...

Hmmm, OK, point taken. For mixed content it seems necessary. How do other scripts deal with this? Do they tag each component part and auto-determine LTR or RTL or do they just use UTF-8 and the characters basically 'determine' the language and explicit LTR or RTL is needed??

Anyways, will consider this for XOOPS core. I think there is a CSS text-alignment directive, e.g. in a 'div' or 'span' which would be preferable to the 'table'. This is because 'table' may have all kinds of other CSS associated with it which might introduce borders and other alignment and percentage widths around the e.g. farsi text. I will look into this.

OK, I think I see what you are saying. I think I was assuming too much this is like the 'multilingual content hack' thread. i.e. I thought you wanted to enter the content of e.g. a news article in multiple languages using the square bracket notation described in that hack. The reason for the language tag is so that only *one* version is shown when someone visits the site. The tag is the only practical way for XOOPS to know which part is to be shown to users who have selected each language. Because you would specify the language, there is no reason it could not automatically know whether that language is RTL or LTR.

What I *think* you mean is that you would enter the post content in one langauge e.g. Farsi, and you want to force this to be RTL with the [rtl] tag. You would never actually indicate this is in Farsi other than the specific characters you had entered... The purpose would be to always show this text as RTL regardless of the "main" langauge of navigation etc. for the site. Is this a correct interpretation of what you mean? If so, I can understand your desire to have RTL.

However, I think XOOPS will eventually have in the core some support for multilingual *content* and as you seem to agree, the rtl/ltr tags would be redundant. I think a lot more discussion is needed on how best to improve the multilingual capabilities of xoops.

Your site takes about 11-12 seconds to load here. I'm near Los Angeles on a T1 connection at my university. I do have a very slow computer though which slows down (a lot) pages with scripts and graphics etc... For comparison xoops.org takes 3-4 seconds to load here.

You might consider upgrading xoops, the latest version stores the javascript in a separate file so it does not have to be loaded with *every* page that is visited.

I think the best (only?) way to do this is to send plain text as the 'body' of the email and send the HTML version as an 'alternate' body. The mailer used by XOOPS I believe supports this but I don't think the HTML aspect is currently being used.

Once it works though, you definitely use real HTML (< and >), not the 'bb code' square brackets.

I think there are some newsletter modules that will do what you want to do. Maybe some hacks to the admin mail users feature exist too... I'm not sure.

There are some other discussions on RTL languages in the forums if you search for them.

However, I think none addresses this point. If the whole site is in one language then you can just set a global LTR or RTL flag for the whole page, but when you have the possibility of mixed languages that breaks down. I think that is what your comment is addressing. e.g. If you use the multilingual content hack with [english]abc[/english][farsi]xyz[/farsi] then sometimes you have to switch text direction. I guess one way is for the multilingual hack to automatically make 'english' text LTR and 'farsi' text 'RTL'. The other option is as you have suggested.. an extra square bracket code for 'rtl' text. I think automatically tying it to the language is the best way to go. Would there be any reason not to do that? Am I maybe misinterpretting your usage?

Anyways, thanks for bringing up this important point, which ties into the multilingual content idea.