I've had to put the update on hold due to some other work that is more pressing, but once I'm done on that, I'll get back to this because there are some upgrade/updates we need on this module.

It's not a lost cause. Overall it works well, but it really needs the presentation layer separated from the code. That's one of the major advantages of XOOPS over the others like phpNuke and postNuke where this code originally came from. I maybe ought to go and see if any updates have happened to that code on those forks before I finalize and publish anything on this.

Well, you could reprogram the module. Are you sure it doesn't go over 100,000? Maybe it does. You could rewrite the template to put the next digit in each time it rolls over. You could congratulate yourself on a job well done and realize that it's the content and not the counter that makes a web site and think about taking it off. Or you could reset it each month. There could be other possibilities, too.

Personally, I recommend against them because usually they are too low to be proud of and once they're big enough the only one that pays attention is the site owner. The site should primarily stand on what it offers.

Congratulations on having to worry about this. BTW, where do I sign up to have one of the babes shipped to my home address?

I, too, have been using XOOPS for almost a year now for sites for self-reliant customers and non-profits. There is so much I've received from this community, and I'm looking for ways to contribute back.

The XOOPS core is actually a very elegant system. I've worked integrating various web technologies since 1993. When I recently leaped into the CMS arena due to market forces, I delved into a number of CMSes from a technical standpoint to better understand their strengths and weaknesses, because I realized I really could only commit to one. XOOPS has a strong technology foundation, community, and support, and it seems to be more flexible than any of the others I played with almost two years ago. With the profiles capability in 2.2.x, it removed a major deficiency (albeit maybe created some incompatibility with previous modules), and the earlier tokens mechanism brought some security especially with easier integration to other systems.

I recognize a few issues and ask a few questions...
* Maybe I missed the major complaints, but I'm also just installing the first v2.2 install as a test site to play with it (yet looked at it some during the 2.1.x phase). I understand a number of modules are running into problems working correctly on the system due to major core re-writing and re-structuring to accomodate the profiles that EVERYONE was asking for. Is there something else I'm missing?
* Are the XOOPS.original core developers incredibly proprietary over this (if so, then I missed it)? I.e., why can't the XOOPS Cube people provide some development on this project in a way that addresses what they feel is missing and is their contribution to the community? Personally, I'm looking for ways to contribute to the project and have done so through some documentation in the DevWiki during my first module project. I had assumed that this project was by it's very nature a community project. A number of people in our make-a-quick-buck society would have rather just figured out how to make a buck off it in a proprietary manner and not share this hard work with others (with very little to no compensation for it).
* How could we who are running into these problems with these modules now have better supported the XOOPS.orig authors who were doing the rewrites? I must admit that I didn't spend time testing the RC versions on my current sites. That's why you don't hear any complaints from me. I've been busy trying to make a living with various projects and implementing XOOPS sites for non-profits (so far) in between. I'm sure that the XOOPS.orig devs are, too (in between spending likely copious amounts of time making our lives easier by developing the XOOPS system). Maybe we need a longer time to try it during the RC stages? Would more of us try it if the RC testing stage was longer or would we continue to wait for the "official, stable" release?
* I guess if I were looking to improve a specific focus area of XOOPS, I'd first contact the developers and discuss this with them. I'd assume that happened here? If so, what was the discussion like? I can't believe that they didn't want the help. Or did the work otherwise interfere with the plan? Is the planning for future XOOPS done in a community way? How is that handled? However, I also know that in volunteer-driven organizations that significant amount of the decision making goes to those actively involved in doing the work. It sounds like they have worked hard to incorporate what they can. Have they also worked to incorporate more developers in the project?

Every time I bring a powerful interactive website to a non-profit that is helping our society in ways innumerable, I thank the developers of this CMS. I hope to be able to donate to them in the future when I use it in a commercial site.

I certainly don't have any ill feelings towards the XOOPS Cube developers. It's generally a free world, with people free to do what they want. Thus, they have every right. I do wonder, though, a lot about why we can't work together towards the same goals. If anyone can clue me/us in to the reasons we can't that would answer a lot of questions from the community standpoint.

And work will continue in the community that each member feels provides the most value to them and the larger community. It would likely be better for all of us if we were to figure out ways to contribute to this single effort rather than divide our energies since generally we all need the same things.

Working together, we can create change and make a difference.

Peace,

Each browser has some differences in how they interpret the CSS you are using, thus the XOOPS design, rightfully so, made accomodations for the different browsers that use the different rendering engines. XOOPS automatically detects the appropriate stylesheet and feeds that one to the browser (try looking at the HEAD information in the source after using both IE and Firefox/Netscape.

Realize, too, there are other CSS files. There is a xoops.css file in the main directory, and there is likely a CSS file in each module, too. These are loaded in order from general to specific: the main one for the CMS (xoops.css), the theme (whatever you specify in your theme), and the module one (whatever is specified in the module and/or in each template as in-line styles). This fits the cascading stylesheets design to a T.

However, most designers design in such a way that they only use stuff that works across all 3 browsers. That being the case, I put this line in the styleMAC and styleNN themes:

Then I don't have to copy and paste the changes in 3 stylesheets.

I've still found that some things don't work as expected at times. If you run into that, then put any browser specific CSS into that specific stylesheet (to load after the main stylesheet, and thus "trumping" it). For instance, in the myReviews module, the "waiting" block uses UL lists which display differently in the Firefox browser (and since I don't have access to a Mac, I have no clue as to how it works there). Thus, I added some specific ones just for the Gecko browser (cause it was easier than figuring out how to make it work for all browsers).

Additionally, for every module that I make, I take all those styles from that style sheet and then paste it into the theme's stylesheet instead. Thus, for my sites that have multiple themes for users to choose from, I only have one place to add/edit those styles and when I add a module, I can make all those changes in one place for each theme and can accomodate those as well as the differences between browsers if any. If the module doesn't specify a CSS it likely uses in-line styles, but you can deal with that pretty easily.

Clear as mud?

You can't use smarty in the custom block code you send because the code is outputting to direct HTML, not through using a smarty template. I think I was confused by what you needed to know.

I'm assuming you are trying to fit some database driven content into a custom block. I get that idea from the include file trying to get the output from one of your module pages and then using that info. I'm not sure that including a file that way will do anything for you. You likely need to include the file via the path if anything.

However, assuming you can do that there is a global variable $xoopsTpl that is used to send data to the smarty template. If smarty template uses it, great, if not, it's just a useless piece of information. However, assuming it's been set and exists through some function, if you can call the variable from the template, you can call it programmatically in your code.

For instance:
Quote:

The other variables you'll need to know the name of, but they likely aren't block=>....

Likely it's just easier to make the direct calls to the database based on code you find in the module and other blocks and just output the HTML you want.

Or you could write another block for the module and update the module. They are fairly easy to add once you take the time to learn how.

Hope this helps.

Instead, you'd need to use $xoopsTpl=>getVar(xoops_url) (or whichever SmartyVar you're trying to use) to use it in the block code. Also, you can assign a template for a block and then use smarty variables in that to display the block.

I had the same problem on a site when I added piCal. I decided it was because of all the links in the calendar itself to each page, then to each month and each month before and after that, I'm assuming to some eternity. If all of your pages link to and from each other, until their bot gets it all figured out, you'll see that. Also each time you add a new entry, then it starts all over again. You might add something to your robots.txt file in the default directory of your webserver to tell the bots not to crawl a certain module.

Hope that helps.

Good luck getting in touch with anyone about this. I've tried a few ways without response. I've been using it, too, on a 2.0.x site. I haven't yet upgraded it to 2.2.x. Did you change versions of PHP? The offset is an array ability to start at 1 instead of the usual 0. Because of what you describe with the blocks, maybe because this is a port of a phpNuke module originally (and it doesn't use Smarty Templates) that's why it's acting strangely. I've been working on an update to it myself since I haven't heard anything for a long time after trying to contact the various authors. I'm a little ways off from releasing and I haven't been testing it against 2.2.x, but I guess I should now that I have one of those sites up now.

Good luck, and if you figure anything out, please let me know as I'd love to incorporate it in an update to this useful module originally written for books but usable for quite a bit (the first time I used it was for a local business directory).

There are a couple of ways to tackle this, but either way, you need to make individual menus for each one to get the type of distinctly different menus you seem to be looking for. These will have to be manually changed as you add modules and the likes, but unless you do major re-programming, you won't do it through smarty templates.

Using either MultiMenu or Custom Blocks, make the individual menu blocks you want for each module (you may have to steal code for custom blocks -- MultiMenu will likely be easier). Then display only that block in each module (using the Groups and Blocks area of the system module to set permissions and viewing).

With what I think you've described, you can't do it with a single block.

Let me know if this isn't understandable.

I had the same problem today on my site. Is there a bug going around? I'm using 2.0.12a. I haven't yet taken the time to update/upgrade to 2.0.13.1, but maybe I need to? Is this an exploit?

My theme was showing just fine, but no block content was showing AT ALL!!! The module pages would work and display, but no blocks were showing. When I went to the System | Groups page and went to check the various permissions, that was all correct. And, when I clicked on a particular block it seemed to be set alright. But, again, none were working.

Anyhoos, what I did to fix it. I tried updating each module per an old posting, but that didn't seem to deal with it. Then I went to the System | Groups page and clicked on the Webmasters group and submitted that. Then I could see them again in the System | Blocks area (after choosing to see those not visible).

Now for some reason or another, they are all working again. Don't ask me what is going on, but I was sorely confused about it all.

Over the past few days, I'd been starting to add caching to my site, but I can't believe that contributes to this. Hope this helps some of you.

Befuddled and almost bemused....