Try removing the HEIGHT=xxx in he TABLE tag, making the table only as high as needed... It will save a lot!

I'd love to have a look at Xoops2. Is it available in anonymous CVS or anything? I apologize that I haven't looked for it yet, so if it's obvious where to get the code, just say so and I'll find it.

Yes, I like your idea about passing an object as the parameter of theme functions. However, in XOOPS2, there will be no theme functions at all, but all the values for presentation are assigned to template variables via the Smarty global object like $smarty->assign('name', $value);.

Yes, the old themes will still work fine in XOOPS2, but since the Smarty template system will be the primary theme system we will be using, it is unlikely that we will be doing any modifications on the current theme system.

Here's another thing that occurred to me re: passing the objects to themes. Perhaps there's already such a document (I apologize if I missed it somewhere), but it might be nice to have theme guidelines that require you to test for the existence of a property before using it.

Here's an example problem: Theme 1 uses $story->title, $story->morelink, etc., which are all standard. Theme 2 uses the field I added to the table as $story->storyurl. At this point, only those people who had my modified code could use my theme. If they used my theme with their unhacked Xoops, my theme would barf when it tries to access $story->storyurl and couldn't find it.

But if I wrote the theme with that in mind (and according to the suggested guidelines), the code would test for the existence of $story->storyurl before trying to use it. That would (or should) make my theme compatible with unhacked versions of Xoops.

Obviously, my example is about hacked versions, but this same principle would apply to prior and future official versions.

Thanks, I've stick'd this for future reference.

1. When you save a submitted article, I'd like it if the code returns you to the module/news/index.php?op=newarticle

Just change the redirect at the end of the save (in the case statement) to this:

redirect_header("index.php?op=newarticle",1,_AM_DBUPDATED);

That way you can continue to preview/approve articles (and if the next suggestion is adopted, move them around). There are probably other places where it would be better to have an operation return you to a more convenient admin location so you don't have to keep navigating the admin menus.

2. Ability to move article positions in the TOC (Table of Contents, or news module home page). I implemented a way to do this in my hacked version of Xoops, but if there's a better way, go for it!

3. Main menu that only shows options available to the group viewing the page. Again, if you like this idea, my hacked version of dynamenu does this (and includes the pretty icons, although some people justifiably don't like icons), so feel free to use that code or if there's a better way, ignore that code.

4. A top_news module that lists the X most recent stories in order of popularity. This avoids the problem of really old articles staying at the top of the counter list. I modified the news_top.php to do this, but I recently realized I could simply have created a new module and left the original code undisturbed. I'll do that and submit it in case anyone wants the same feature.

5. Pass an object to the theme handlers instead of variables. That way people can customize things to a greater extent without breaking existing themes. In other words, suppose you pass the object $article to themenews($article). Your standard themes would access the variables through $article->title, $article->morelink, etc. Now, if I decide to add $article->storyurl as a property, the old themes will simply ignore it and continue to work, but new themes can make use of the additional information. All the themes can coexist happily on the same site. (Yes, I know you can add parameters at the end of the list to get approximately the same behavior, but IMO that's a sloppier and more error-prone way to do it.)

6. Indeed, pass objects (or arrays) whenever possible to make backward compatibility easier at all levels.

I did know your hack before the ldap XOOPS release.
Sorry I made the project name as 'ldap xoops'.It means
'a LDAP case base at XOOPS', not official ldap support.
It isn't a hack.It use ldap as DB background not mysql.
I want to use it as a webmail system and CA center front.
So you can find a webmail module in demo.

We haven't written any LDAP code for XOOPS 2.0. We just opened it up so the authentication can be modular making it easier to add an LDAP component.

Hi,

There was another LDAP code. A hack for RC 3.0.4 core code. Did you look that code or did you write from scratch?

the demo site are not working nothing good :(

nut the concept is SPECTACULAR.