You can easily do this in a couple of steps.

First you need to set a style, either directly in the page, or within the style sheet file for the theme you are using (aptly named style.css)

Create two classes (for example):

.blue
.white

The period is necessary because it defines this style as a class which you can later add to your row's tag.

For each class define their respective styles, in this case you would have something similar to:

.blue {background-color: #0000FF;}
.white {background-color: #FFFFFF;}

Now that you have this defined you can move on to the having XOOPS handle the cycling of the different classes on your row.

In a template or on the theme file, etc., you will need change the variables for your table row and should end up with something like:

<tr class="<{cycle values="blue,white"}>">

Traditionally you you have had to do this row by row (i.e. class="blue" then on the next row, class="white", etc.), or used javascript to handle this, however XOOPS takes care of this nicely via the "cycle values."

Note: don't forget both brackets AND both braces.

Chris

The footer displays great, however it is not what was entered in the admin part under meta tags and footer.

I checked out the footer.php file and can see that what is showing is hard-coded into the file rather than pulling the info from the DB.

Question: How can I change the footer.php file to pull the data which I entered via the "meta tags and footer" part of the admin section? (or if I have this all backwards then what

Thanks,

Chris

I finally figured it out:

Quote:

That should do it.

Chris

The saga continues.

The AND statement is pulling in all the records though the platform is not there.

...

Though I had it working, I did try your suggestion - didn't work, but thanks anyway!

I do have one question though about the slight difference between the string I started with (the first of the two lines in that particular file):
Quote:

and what I ended up with that appears to work:
Quote:

The first one had the '%$queryarray[0]%', the second had [0] replaced with [i].
What doesn't make sence to me is that, what would seem logical is what was the value of [0] would remain [0] and not [i]. Anyhow, I wouldn't have stumbled on that had you not given me the first bit of info.

Thanks!

Chris

I played around with your string:

Quote:

and came up with the following that seems to work:

Quote:

I did like you said:

Quote:

But I still don't get anything.

When I changed the d.title to d.platform, of course that field started showing, however with the other now excluded.

Ok, I found the search.inc.php file and added d.platform (the field I want included in the search) and updated the module. However I am still coming up short...

I have a modified module based of mydownloads and recently noticed that when I use the search function that is does find content in the body, or rather, the description however is fails to search within the platform tables.

Is there a way to include this field so that the search function would not pass it over?

Chris

I believe that one of XOOPS best features is not being acknowledged, that being the simplicity of not just administrating but with assigning various groups certain privilages, such as adding content.

Certainly most admins don't shy away from hacking here and there, and easily will adjust to using brackets, however I think we are seeing trees and not the forest for what it is.

I am currently working on a multilingual site with both Russian and English and cannot expect, nor really want to go to the trouble to teach people I am intending to post content, on how to properly use square brackets. To you an me this may be a simple thing but what about others? (This does not even address what has already been brought up concerning unecessary data passing through the TextSanitizer)

I feel at the table level a field should be added specificaly for languages, and as content is added, the language is selected. If you want your content sent to all then code can be written to pass everything through.

For example, my Russian half of the site will be different than the English. Why should I have somebody looking for Russian only content have to sift through English? A great example, though not necessarily the only one would be the way PostNuke handles languages (though I am not familiar with how their code works behind it, I am only referring to the tables).

Does that make any sence?

Chris