For those who run across this issue in the future, I managed to solve the problem, more or less, by inputting the Japanese directly through the filemanager in control panel. Doing so changes the characters into unicode [eg の] which means they'll display okay on the page but are indecipherable in HTML view, making them uneditable.

These are the kinds of issues I'm coming to despise more and more about XOOPS in particular and PHP in general: what a colossal waste of time. It all too frequently takes 5 or 6 hours to overcome something that could be dealt with in a matter of moments in straight up HTML. If I can find an easy way out, I'll take it.

I tried adding some Japanese content directly into the theme.html file at my site and for some reason cannot get it to display correctly. The site content -- which is primarily Japanese -- displays okay but the stuff embedded into the theme.html file is all garbled up.

When I change the page encoding in Internet Explorer 6 the theme changes display OK but all of the site content becomes garbled. It seems to be a kind of one or the other situation. I can't get both the site content and the theme changes to display correctly at the same time.

I've tried changing the XOOPS language variable in the theme meta tag but the result was the same. I've also tried setting lang=ja through the div tags but the result was the same. I've also checked around XOOPS Japan for similar issues but turned up nothing. Any idea what's going on? It's like the theme is going through a shredder before picking up the content from the database.

You hit the nail on the head mikeh. Carnuke and herko, you just restated what I already described as royal pains in the butt. No soup for you There are times when others are adding content but you don't really want them in the admin area. So how can they refresh the page?

You know what XOOPS needs? A dedicated refresh button. You know, we when you have to claw your way into the admin section, drill down into the system module, tear open the user preferences then slam on the OK button before dragging your sorry, tired butt back through three or four page loads to wherever you were working.

Wouldn't it be great if there was a tiny little block with a tiny little button on every page, hidden from normal view, that site administrators could just punch whenever we need to reload the entire site. Add in a second button that could toggle theme reloads on and off and you got a dynamite little timesaver with the potential to eliminate dozens upon dozens of unnecessary page loads on a particularly busy day.

Yes, I already have a refresh item on my main menu, hidden from popular view, that tunnels on through to system/user preferences but still reloading the site requires at least two superfluous page scrolls and two page loads and possibly four more to get back where I started. Try that 15 to 20 times a day and it's a colossal time waster. Worse, it can rattle your concentration. And yes I do use two browser windows: what a hassle. Couldn't something like this be achieved relatively easily?

Thanks. I couldn't force my ip address to change.

Could some one go to my website and click on the any of the choices in the poll? I want to see if it is allowing anonymous voting. The poll is on the bottom right of the mainpage. Thanks

Well that didn't work and even if it had I'm not exactly comfortable with the need to add JavaScript statements to the theme head tag every time I need to use a bit of JavaScript. Once or twice might be okay but what if, over time, I need a couple hundred different JavaScript statements? The idea behind using a CMS is to speedily add content to a site. All this hacking seems to defeat that purpose.

What I think I understand is that, even in a module such as Tiny D or WF Sections that purports to "wrap" HTML documents inside of Xoops, this is going on: The head tag in the imported document is being ignored and the head tag of the theme is being used. Is there any way to force XOOPS to use the head tag from the imported document instead?

Beyond that I think I need to look at using pop-ups to access outside documents for this kind of content. That would require a one-time hack only. Alternatively, I should look at building these kind of interactive apps in flash or shockwave. Any thoughts? Comments?

Firefox users only account for 5% of my traffic but no doubt that will grow. It's definitely a concern. I've also had problems displaying flash correctly in the whole family of Mozilla browsers.

Thanks James. I think I understand no why the tables wouldn't work. I'm guessing that the cell padding/spacing are being disabled with the Theme CSS. That's why you needed to include the style="padding:1px;" with the TD tag. I tried it out and it works like a charm.

On the other hand, I still can't get the JavaScript to function correctly. Check Here and mouse over the stars. ToolTips are supposed to pop up at the cursor but instead I get very erratic behaviour. This is how it is supposed to look: Same code outside of Xoops. Any ideas?

Thanks, JMorris, for the insights into how module development works.

Let me see if I can elucidate my dilemma a bit better. The problem is that I can usually find one module or another that will display my content but it's usually a hit and miss -- and very time-consuming -- proposition. Not to single out any module and trash it; that's not what this is about. Let me provide a few examples.

A while back I wanted to create a simple four column layout using a table with four photos across the top and cutlines across the bottom: simple static content that could be easily updated on a regular basis. First I tried a custom block but that didn't allow tables. Next I think I tried News and had some other problems but I can't remember offhand what they were. Then I tried WF Channel and it allowed for tables if I remember correctly but didn't allow for cell padding so the content was all jammed up together, one column jammed into the other with no breathing room. Finally I downloaded and installed Tiny D and it worked and it's still being used to display the content at the bottom of this page here:http://www.hima-ari.com. It's not like what I'm trying to do is really seriously challenging stuff. This is really basic yet it took an awful lot of work to get there. I cite this as a simple example for illustration purposes only and in no way am I attempting to belittle the efforts of any module developers.

Now for a more complex example:

Over two sites I have approaching 1500 pages of content in two different languages. Obviously I need something approaching reliability to manage all that.

Let's look only at the site mentioned above. I'm using XF Section for the bulk of the Japanese content and Articles for most of the English content. Say for instance I decided to put together a 10 part series on the ins and outs of studying English in Canada. I want it in Japanese for our primary readership and in English to demonstrate the content to potential advertisers.

So I decide to work on the English part first as it's easier for me to work in English. Say the first two entries are fairly straightforward, some text and graphics. Fine. So say I continue to use the Articles module to display them in. No problem so far and it connects up with all the other English content. Bonus! Then I need to add some shockwave content in the next installment. I can't remember if Articles works with shockwave or not but let's say it doesn't just for the sake of illustration. So I try something else out. Again just for illustration purposes let's say I get the shockwave working in WF Channel. That's a relief. So reluctantly I move the first three articles in this series over to WF Channel, tweak menus, tweak blocks and placement and then get down to the fourth article. Well this one requires some JavaScript. When all is said and done I can't get the JavaScript working without a lot of extra line breaks in WF Channel. So I try out something like Tiny D. Maybe it works. I don't know. I can't remember. I've been bouncing around between so many different so-called content management modules that I haven't a clue anymore which ones work with what. The point of all this being that none of them work with everything; not even close to everything. And because of that it's increasingly difficult to create any sense of continuity.

I understood what you were saying about the difference between CMS and CMF and, while I'm sure there are good reasons for taking that approach, from the point of view of content managers it sounds like a tragedy. From the point of view of operating a functional site and delivering content to end users it sounds like the cart is before the horse. Shouldn't the core be built around a kickass content module rather than like a doughnut with this gigantic hole in the middle?

Perhaps this sums up what is going on. XOOPS and a lot of these PHP portals are crucibles for honing and showcasing the skills of the developers. But the developers, not being content deliverers in the true sense of the phrase, are working in a vacuum, developing for imagined needs rather than real world ones. Ultimately, if the CMS/CMF can't really be put to work managing the complex needs of content delivery, then it fails as a showcase for the skills of those developers, doesn't it?

I certainly haven't decided to chuck it all as far as XOOPS is concerned but I'm very, very worried. I've invested an awful lot of energy and now I'm just starting to realize that perhaps XOOPS will never be able to meet my needs. Do I want to try another CMS? I'm certainly willing to take a second look. Should I go back to straight HTML, plunking in bits and pieces of PHP as appropriate? I'm not sure. I'm really not sure.

Quote:

1] Text, graphics, and multimedia.
2] It should be close enough. If our lexicon doesn't share meaning then there is no way we can communicate.
3] I don't know. That's why I posted.
4] A party ? Did someone say a party? Let's go!