Grand idea, although if we in the module repository itself we could add the version it supports and to search based on which versions the module supports, that might even be immensely valuable and easier in the future when trying to figure out which supports what.

I haven't played with 2.2 yet (too busy implementing the still-being-understood 2.0.x), but I assume from the discussion and release notes that there are major underlying changes that prevent modules from being forward compatible. Do they all need complete rewrites underneath?

If it's colors or layout description, then you can make changes in the appropriate stylesheet. If you feel that you need to re-organize the information on the screen, then you need to hit the appropriate template(s).

Basically, you'd need to change the template for CBB to be like the template for NewBB. The same developers developed both, so they should be similar generally. You may have to understand the styles, and see if the styles are being pulled from the template's/module's css, the theme's css, or the XOOPS root css. I usually put them in the theme or the module css and override the root.

I've been working to modify one myself, changing out graphics and the likes. It's really not too hard. Remember to keep track of the file changes you make for upgrading your site in the future.

Is there any way to include a block inline in a module? I.e., can I call a function to create a block within the php code of my module and then include that information to variables to use in the module's template?

I have a couple of modules that share a block (from a third module) that our site wants included instead within the layout of the module. Design-wise it makes sense. If I could fairly easily call and include the block in-line in the module code and specify the output to the template, that would make it easier than some other hacks i've made. The biggest thing I've run into is dealing with the constants (/<language>/blocks.php) not being automatically loaded.

It might even allow other things that would allow the developer to check and make sure the block exists first. I searched around but couldn't find it. If anyone has done this, I'd love to get your insight instead of reverse-engineering that part of the code or continuing my hack.

It's likely because of your customer's firewall settings removing the referer information. Read this good explanation. And then read how to fix it.

I'm assuming eventually this will all be done with security tokens that were introduced in 2.0.10 (I think).

A module developed to XOOPS standards uses a template and can also included a stylesheet to be used along with it. CBB, like NewBB, uses templates that reference a stylesheet. There are additional stylesheets for the menu as well. All of these are in the /newbb/templates directory.

Likewise, templates for any module are kept in the /<modulename>/templates directory because of the way XOOPS is programmed, while CSS can be anywhere because it's included differently. Usually, the CSS files are in the templates directory, but I've seen them in the includes directory, too.

Alternatively, you can just edit the templates and reference class definitions from your main theme(s). I often do that and if you allow multiple themes to be chosen by your users, then the modules change as well.

Hope that helps.

Yes, thanks. Great application and great site. I've used XOOPS for a few non-profit customers. We're now using it in a new project we're coding for a customer and have been using this site and the information extensively. Was really set back while the site was down. Glad it's back up.

A couple of questions. You lost files. Is the server not backed up or were backups unavailable? Is this being dealt with on this new server?

Also, I have a number of the modules that you indicated were missing. I know that some of them that I downloaded from here were from people/sites that I've no longer been able to contact. I can provide a list. Some I know are very well supported and I expect those to be back up in the next day or two as word filters around that the site is back up.

Thanks again,

I was having the same problem. I finally tried XOBJ_DTYPE_OTHER and it worked just fine. So, I searched through the XoopsObject code and found the serialization issue. Then I searched these forums for an answer.

I'd have to agree with succhi that this should be transparent for symmetry purposes just as in the other data types. I should be able to just send the array when I use the assignVar or setVar instead of manually serializing it in my code first. I spent over an hour on this little bitty issue.

It would be easy to add a switch to the setVar and assignVar areas (I'd be happy to write and submit the code). But, I wonder how much usage is made of this because the "fix" would (could?) break others code. I did a quick search on the core and the modules that I regularly use. Not a lot of usage generally and NONE in the core (interesting, eh?). CBB (and likely NewBB2) and Liase are the only module usages I see (of the ones I use regularly).

I'll post it as a bug since I couldn't find it listed on SourceForge. I guess it's always possible this is by design, but there aren't any notes to that effect. How many modules will it break if we were to "fix" this?

I think for now, I'll just use the OTHER object type and examine my arrays myself. That way if it ever is dealt with, then I'll only have to change the object type in the class rather than remove a bunch of serialize() statements and worry about compatibility.

Any comments on this issue from Core developers?