Ah yes, one thing I forgot to add about Typo3. I noticed that in their roadmap they talk about adding "staging". In other words, the ability to put the entire web site out to flat files. Now THAT is a function I would like to have. That way, if for some awful reason my entire site goes belly-up, the XOOPS team loses interest, or any other major catastrophe happens, I can get my site up and running in bog-standard HTML anywhere in the world. I see the light!!
But Typo3 is still too complicated for anyone who doesn't need full-blown professional site I think

Well this is a very interesting discussion and so I will add my pennyworth.
I have been hacking around for quite a while new to find a suitable CMS for several sites I want to set up (which is taking a VERY long time, for reasons nothing to do with the technical).
I'm looking for something that is easy to learn, requires NO programming, and (of course) has the features I want. Here are some comments from the first site I'm developing:
Typo3 - great system, undoubtedly far more flexible than any of the others, as someone said a "professional" package. BUT way too complicated.
Envolution - liked the language support (allows you to attach a language flag to every piece of content or structure): hated the admin interface, especially the security feature; also hated the really arrogant techno-nerd type community response I got to my newbie questions (and in general - I keep seeing posts where they slag off other developers )
Xoops - didn't like some things (no proper language support for one), but loved the simplicity and the nice clean look, easy admin interface on balance, good selection of extra modules... and I was already to go BUT fell down on the user permissions in articles and wf-sections (I've already posted on this subject).
Tikiwiki: I finally chose Tikiwiki, which has very extensive permissions and is quite easy to use and understand, reasonably clean interface, did what I wanted for the first effort.

Now I'm back again for another site, and what is critical here is the search engine support (both inside and outside the site). I've posted on this subject too and would be very glad of an answer. But I'm surprised that in the list of CMS that people have looked at there is not Drupal which seems to have nice clean interface, fast loading, and very good taxonomy management for sites with complex, deep content. Also absolutely clean URLs. And by the way, there is no conflict between taxonomy and search - indeed the one should be a support for the other...

Any comments on this and my other posts would be most welcome.

JoelG

I've been looking around on the site but can't find the answer to my question - maybe it's me, but I would appreciate some help.

I am looking for a package to replace a site currently based on framesets and articles in individual files, for a history magazine site (in fact I've already posted a question about importing the existing site into XOOPS - help welcome there too ). This framesets technique has disadvantages, but it also has one big advantage: it is very easy (using OpenOffice) to give every article a metadata "content" and "description" (as well as a title) which will show up nice and cleanly in the search engine results (the disadvantage is that users get directed to the individual page minus the frameset, but there are ways round that).

Since the site I'm working on has extremely varied content, I'm reluctant to lose this feature since it would be impossible to update the metadata at the site level, in such a way as to reflect the richness and variety of content in the site, using:
META NAME="DESCRIPTION" CONTENT="description"
META NAME="KEYWORDS" CONTENT="keywords"

I'm looking for a PHP/SQL based Open Source CMS which will therefore have the ability to associate meta content and description with each "page" (ie and above all article). Even better if it can do it in the Dublin Core standard.

I would also like to know about the internal XOOPS search engine. What are the limitations to it? Does it just do search on title, keywords for example, or can it handle full text? Can it handle the content of file downloads (notably PDF?).

Many thanks for the help

Joel

I’m looking for a PHP/MySQL based CMS to replace my existing site.
The existing site is a magazine site built using framesets : each article is a separate HTML or PDF file, with its own metadat exposed to search robots.
The articles are not ephemeral. The aim of the site is both to provide lively and regularly updated news items, and a searchable archive which will grow over the years. There is no plan to purge articles.

I'm concerned about potential issues of backward and forwards compatibility, and would be very grateful if somebody could give me pointers to the following two issues:
1. Backwards compatibility. The site is currently based on a large number of articles, each in a separate HTML file. There should be some means of incorporating these files into the CMS without having to load them all in by hand.
2. Forwards compatibility : in the event of the site moving to different technology, it must be possible to unload the content into a standard format (HTML) such that it can easily be used to build another site. This might be provided by a backup function, or by staging the CMS into flat files (this is a standard technique in a commercial CMS, which uses the DB-driven front end for developing the site, but then exports the whole site to a flat file cache for greater speed).

Many thanks, Joel

I've just started getting into wf-sections and trying to do some "life-size" testing, and I come up with a problem: an apparent limit on text size.

I have a text of 6000 words (about 50K characters) that I want to put into a single wf-section in the window. I copy-paste from the original word document, everything seems to go fine... but only about half the text is there. Is there some configuration issue here (either in PHP, MySQL, or XOOPS itself?).

Help would be appreciated, since otherwise I will just have to stick to my original flat file layout!

All the best, Joel

Don't forget. You need to think hard about specifying the code pages for the different languages, and also making sure that the interface for entering content doesn't do nasty things to the content (like converting it to "&xxxx" ) when you enter it, no matter what your local machine's settings (eg entering Russian from French Windows/XP!!)

I don't really feel fitted to get into a deep technical discussion, however here are a few thoughts in not a very particular order:

1) There seem to be two kind of language requirements for web sites: either the languages are completely different (ie different content in each language), or they are complementary (ie the same content published in 'n' different translations). It should be possible to handle both.
In the former case, it is fairly simple, you can do it like eNvolution where EVERYTHING that could appear on the page has a language parameter (blocks, modules, articles, you name it). The parameter includes "all". Depending on which language the user chooses, then he will see content for that language. This would also mean "detaching" blocks from modules, so that I could have 'n' blocks using the same module, but for different content.
In the latter case it is a bit more complicated, because you would want to make the level 'article' (or 'topic' or 'section' etc etc) into a link, so that for example I could instanciate the same article 'n' times in different languages. Oooff!

2) Separate admin and content. Admin language means translating the whole system's admin menu. Content language should merely allow you to add another language parameter to the system, perhaps with a few attributes such as character set for content entry (definitely NOT hard-coded, otherwise how do I choose the multiple different versions of Korean for example) and with total support for Unicode.

3) Keep it in one database - no point in doubling up a lot of tables you won't necessarily use.

4) Definitely provide an alternative to square brackets. All honour to the hackers who thought this up, BUT in a world of multi-lingual and non-technical users spread around the world, believe me it is EXTREMELY DIFFICULT to explain the simplest imaginable things, and to a non-techie square brackets AIN'T SIMPLE!!

My pennyworth for now, and if anyone can help with my user permissions problem, I'ld be grateful!!

JoelG

I have a major problem with user security using wf-sections - however I get the problem that the problem is basically the same with any other module. I'ld be grateful if somebody could tell me whether I have just misunderstood how to get the result I need, or whether this is a real problem in Xoops.

My requirement seems to me very simple. I want to set up several sections on the site, each of which can only be UPDATED by a particular user group. However, ALL sections should be VISIBLE to ALL user groups.

Now, in wf-sections, if I set up a section to be accessible by one group and not others, then the other user groups can not only not update that section, they cannot see it either.

On the other hand, I can set up a group which can access all the sections, but is not allowed (in group permissions) ADMIN access to the sections. That way it can see all the sections, but it cannot update any of them. That is not what I want either.

It seems to me that what is missing is this. When you create a section, instead of just the option to allow "access" to one or several groups, you should have the ability to allow ADMIN access and READ-ONLY access SEPARATELY. This is the only solution that seems to me coherent and will mean that I don't have to create extra groups for updating and for viewing content.

And here is another problem: I want to be able to set up some sections such that the articles posted by the authorised group are automatically approved, while other sections have to get the posted articles approved by a moderator. So here are two more improvement requests for wf-sections:
1) Take the "Auto approve submitted articles?" parameter from the General configuration and put it at the level of each section.
2) Configure a user, or a group as a moderator for each section.

If anyone can see an inaccuracy in this, or point me to a hack or a way round the problem, I would be grateful.

Otherwise, what chance of getting these improvements in wf-sections, and therefore sections later?

All the best, keep xooping, Joel

On point (3) - displaying text in Russian (or indeed any other single-byte language), in such a way that it does not get converted into HTML ampersands (which I feel sure won't get found in the search engines, though this is just gut reaction on my part), I'm very happy to have something to contribute. Credit though goes to Alexandere Vasic aka Alexxus <eccelsiore@gmx.net> of xoops.ru for the solution. It is this:

see global.php in root/languages/english

use (on the end of file)

define('_CHARSET', 'windows-1251');
define('_LANGCODE', 'ru');
define("XOOPS_USE_MULTIBYTES", "0");

Windows-1251 is the Windows version of Cyrillic, but I decided to use UTF-8 instead, since I reckoned that this would allow for all the German characters that I also need, whereas Windows-1251 only allows (I think) for US Ascii plus Cyrillic. At the moment, it seems to work

On point (4), my difficulty is that I have decided to use wf-sections for managing the articles on the site, but there are a certain number of "static" pages (contact us, publication prices, stuff like that), where ideally I just want to put in some HTML written up on OpenOffice, and be able to reach it from the main menu. To me, this means that I should be able to simply add a custom block, then add a reference to the custom block in the main menu. The custom block won't appear unless I click on the reference in the menu. In fact I want something that looks like the menu on www.xoops.org!! It seems a simple thing to want, but there doesn't appear to be any way of doing that, and I'm beginning to think I need to load another module somewhere to make it work. But which one?

On (5), I meant a list of callable functions in the templates.

Thanks for the answer, but could I have some more detail on the following points:

1) Documentation: good luck to those working on it
2) I've seen the "multi lingual hack" and might try using it, but I'ms still confused about how to install a language. Will installing one language wipe out another or can several languages live happily side by side?
3) Thanks to colleagues on the XOOPS Russian site, I found out how to fix this by modifying global.php and setting the code page to UTF-8
4) I would REALLY APPRECIATE some help on how to determine where blocks are or are not shown. I don't understand the "visible in" parameter at all. I can either show things in "top page" or "all pages" or... what?
5) A list would be useful but for the moment I will try to avoid lots oc customisation...

Thanks to all, Joelg