I'm not interested in causing a kerfuffle but I'm getting increasingly frustrated with the various content management modules available for Xoops. I understand that it is a humongous undertaking to create a module in PHP for managing all of the complex aspects of a good content delivery system. In the module repository of XOOPS there are a good half dozen or more document managers, all with rudimentary capabilities but none as robust as even the simplest freeware HTML editor. Not to single anyone out but I'm referring to things like News, Tiny D, Articles, ARMS, WF Section, XF Section, WF Channel and so on in no particular order. All are in various stages of development and all are moving forward toward essentially the same goal. Yet none seem capable of handling anything much more sophisticated than placing text and a few images on the page. Nearly every day now I try to add a little content here, add a little eye candy there, add a bit of interactivity over there and the whole thing ends up just getting messed up, breaking out of the page or adding in excessive line breaks [even with XOOPS codes disabled] or not working at all other than to display garbled text. This is not a criticism this is just simply a statement of where things seem to be from the point of view of a heavy content creator.

My comment then is this: with so much energy going into reinventing the wheel wouldn't it make more sense for all these developers and development teams to put their heads together and create the document management system to end all document management systems? Something that can handle “advanced” HTML like tables for instance, JavaScript, Flash and Shockwave with equal aplomb. Or better yet create two development teams along with a sponsored competition to provide motivation and reward. Such a process could start with a call for features and functionality from the wider community, ending with the adoption of the best implementation into the core.

As things are I'm increasingly beginning to think I made a mistake in going with Xoops. Initially, I checked out at least a dozen other systems. I was originally drawn to the fact that the XOOPS Japanese language development community seems particularly active. More and more it seems like XOOPS is a content management system that doesn't really manage content. Lots of things sort of work but not really. This is a fatal flaw in my estimation. I have all the respect in the world for the development community and what they have created. It is truly awesome. Yet I'm sure that I'm not the only one who has run up against some severe limitations in the handling of content. I don't know. Am I way off base? What do others think?

1. What is "content" for you?
2. Does your understanding of term "content" must be same as my, his, her?
3. How much is amount of XOOPS users, which support your position?
4. How much is a party of opposite opinion?

find these answers, they will say you rest...
XOOPS is system for managing integrated content, while you search something, that will handle your exclisive, whimsical, fanciful and in essence static content, which is absolutely different game

What are you trying to create?

I've never had a problem adding whatever tables or any kind of layout necessary to a page in WF-Channel. It's just a plain container for HTML, what's the problem?

If your major issues are layout related, perhaps the problem lies with the configuration of your theme and templates, and not with the modules in particular.

I would agree that overall, XOOPS lacks a kickass document management and content management system. I would hesitate to lump all the modules you mentioned together though. Some are aimed squarely at static content within a site, while others are aimed at document and article management.

Why are there so many? Maybe because it's too easy to just make your own module or fork an existing one. PHP is a pretty easy programming language to learn the basics in -- but learning how to manage a multi-developer software project is not so easy to learn. XOOPS' biggest problem is probably the relative inexperience of most of the the community in terms of managing development projects larger than one developer in size.

<obligatory plug for Formulize>
We have built at least one site with a complete content management system of its own created using our Formulize and Pageworks modules. The article entry forms were created in Formulize, and then custom pages were designed in Pageworks that brought in the necessary entries in the necessary forms and displayed the content in whatever way we wanted. Each section in the site used its own Pageworks pages and drew articles from its own forms.

We liked this because it gave us total control over the layout, and the data structure, and in that particular site it also let us create forms with dedicated spaces for the English and French versions of articles, since using both languages was a key requirement of that site. We liked that approach a whole lot better than wrapping entire articles in language tags!

http://www.freeformsolutions.ca/formulize

And we are of course eagerly seeking collaborators.

</obligatory plug for Formulize>

Good luck with your site,

--Julian

Quote:

Now that's a good idea!

Quote:

I'm sorry that you feel you made a mistake. Perhaps it would help if a clear definition of XOOPS was known to the end user.

I've come to find (after 2 years using XOOPS) that XOOPS is less of a CMS (Content Management System) and more of a CMF (Content Management Framework). On the surface, it may seem like semantics that seperate the two, but its not.

A CMS typically has advanced features built into it's core that enable content publication "out of the box". Whereas a CMF is more of a API where 3rd party developers produce modules that give the CMF its content management functionality. With XOOPS 2.0.x, this was not clear because of the bundling of CMS type modules with the core. With XOOPS 2.2.x, it has become increasingly clear that CMS functionality will be the responsibility of module developers.

The 2.2.x model allows the Core Developers to focus on stability and security, while providing the module developers with a standardized API that allows for an enormous amount of flexibility in content management module development.

Of course, the beauty of XOOPS is that it has all the flexibility of traditional static web sites, while providing for a streamlined administrative interface. I've actually coded entire websites with only one *real* module installed (contact). The rest of the site was built using an empty module (MyPage) and strategic block placement. And with a little imagination, you can code any language (HTML, CSS, ASP, JSP, PHP, CFM, Perl, etc.) you desire into a XOOPS site.

Perhaps it would be best if a clearer picture of XOOPS was painted. In the meantime, I hope this has been, at least, a little helpful.

Best Regards,

James

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!

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:

Here are some examples of using custom code in custom blocks. All of these examples work with the XOOPS native block manager. So, in a sense, there is native content management functionality in XOOPS (all versions), but only basic.

HTML example (Set Content Type to HTML):


Javascript example (Set Content Type to HTML):


Macromedia Flash example (Set Content Type to HTML):


PHP Example (Set Content Type to PHP):


As far as including an awesome content management module in the core goes... I really don't feel that this is in the best interest of XOOPS. If you remove competition entirely, then quality and features suffer. By outsourcing the responsibility of creating a top-notch content management module to third-party developers, the community benefits by having a selection of modules that meet different needs.

Granted, in your situation, none of the current modules meet your needs, but you are an exception. That's not to say that you shouldn't request the features you want. In fact, I'm sure the developers of the various content modules would welcome a feature request.

My suggestion is that you find the module(s) that comes closest to what you are looking for and contact the developer of that module.

Also, some of the content management modules for XOOPS have support for Kovi editor and HTML Area. Those plug-ins offer a tremendous amount of WYSIWYG editing features.

As far as custom coding specific code into your content goes, that's where custom blocks really shine! There is a tremendous amount of flexibility in what you can do with them if they are used correctly.

Hope this is helpful.

James

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?

At first glance, I believe the problem is that you don't have the javascript included in your theme header. When I viewed the source of the working page, I found the following between the head tags:

Style elements that need to be moved to your theme's style.css:



Javascript elements that need to be moved inside the <head></head> tags of your theme.html:



Once you put those codes in the right place, your block code *should* work.

BTW, the javascript doesn't work with Firefox.

Hope this helps.

James

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.