where can i find the Admin Theme Manager? i cant seem to find it in my XOOPS 2..

thanks

Quote:
AFAIK, you can write a very simple module to do this, but it's kind of (read as "very much") a hack. Here's an example which creates a like to The EFF (where you should immediately go and donate if you haven't done so recently). This example also creates a sub menu with a "donate" link (however, you should be careful with sub menus, because some themes won't display them unless you're actually in that module, which will never happen here). Create the following files:



I think that should work. It's a total hack though. Are there any other easier ways that anyone else out there knows of?

how can i add external link on main menu navigation?

I think the same code is used for all XOOPS comments, it's handled in one object that does all the html stripping and converts the [square-brackets] tags to their equivalent html. Adding the things you're wanting would only be a matter of a few regexp's and some database hits, and it would be a really cool for a church site or another Christian Community-type site. (getting it to do red letters, now that would be tougher.)

I wrote a function a while back that would take arguments of book, chapter, and verse, and hit a database and return the KJV text of the verse. I was pondering at the time the idea of doing the same thing you're wanting, but it was just one of those Saturday morning "I wonder if I can do this?" kind of hacks and I got distracted with other things and never finished it out.

I just spent a while looking around for my code, and I fear I might have deleted it in one of my system upgrade rampages. I did find the MySQL dump of the KJV Bible if it would help. Hey, if nothing comes up this Saturday I could probably code the thing, but I can't make any promises about that. I also have the KJV in XML and some other Bible markup language. (I don't think the KJV is the "one true translation" or anything, it just seems to be the one most frequently located in such hackable data formats. ) Just lemme know if any of those interest you, I would just spam you with them but they're a good few MB apiece.

Hi. This is, in essence, an answer I wrote recently for the spanish forum, about theme building. It might be useful here, so I made this translation. I added some stuff, the text between brackets [].

1) XOOPS2 does actually ease the handling of themes because, unlike other systems, which assemble pages using page segments (the header and the left navigation in one file, the right navigation and the footer in another, and the content modules in the center), in XOOPS2 you have a single HTML file (theme.html), and you write inside the code variables and conditional tags to define what's displayed to the final user. Having the theme page in a single file certainly makes the job easier.

2) Let me see if I can "define" the difference between templates and themes. We might say the theme is something like a "skin", that is, a theme conveys the visual solution of a site. On the other side, a template solves the relation between the theme and the data kept in the database: the template defines what variables to get under what conditions. In XOOPS2 RC3 this is assembled as follows:

a) The theme (basically, the theme.html file, the global images and the stylesheets) are kept in a folder, to facilitate their modification and upgrading.

b) The templates, that also exist physically as files, are kept in the system within the database. I've found that in order to change a template, the best way to do it is to try your changes in an external file. Once you've solved the basic stuff, look forthe template file (as administrator), paste the template code in the textarea, run tests and then work in the fine detail until things display the way you want.

c) The system has other files, more tied to the programming logic than to the presentation, but sometimes you have no other choice but to open them. Basically they're PHP files that configure the assigning of variables (remember, this works with Smarty) and the access to the database. The less you mess with this files, the better.

3) Editing a theme is absolutely easier if you have in your PC a web server. That's the way I do it: I have a complete environment with Apache friend's WAMPP (Apache, PHP, MySQL, etc.) and I run everything locally first. Once you complete your theme, you export it to a tar.gz file, and you can upload that file to your public web server. Obviously there are things to arrange (watch for paths, images and other included files), but as a general rule it's easier to develop locally and upload once you have ironed out most of the bugs. NOTE: Most of the nice things you won't be able to see using Dreamweaver (or GoLive, or FrontPage), because of the simple fact that pages are built dinamically; this means you can see the skeleton of your theme, but not the actual output with real content. [This is particularly true if you design your pages using positional CSS, because all of these tools do a poor job when rendering DIVs.]

4) You've been told about the difference between the various stylesheets. I'll just add the fact that having three files allows you to be very precise in the display for three very different worlds: the generic world of MSIE and other like browsers, the new Netscape world (versions 6.2 and above; nothing here applies for versions 4.76 and before), and the world of Macintosh computers.

5) To develop a theme, I'd guess the most useful strategy --or at least the one I'd recommend-- is to take a very deep look at an existing theme of your choice [and everyday the paper boy brings more...], let's say the default theme or the X2T theme. Once you grasp how the page is made, you'll understand why I say: want a theme? Create it from zero --but using your favorite theme as a guideline.

6) And last but not least, the difference between modules and blocks is fundamental. A module is a complete subsystem that deals with the management and display of one type of content. For instance, the FAQ module lets you manage the frequently asked questions (add, edit, delete) and also lets you define the way the FAQs will display within your site. A block is like the expression of a module in the site. This expression comprises both the data shown and the styling used to display the data. So, we might say that both modules and blocks are programmed. not designed; you design the theme to describe, at the very least the general displaying frame used in the site; then, and this is optional, you extend your design philosophy to whatever templates you'd like to change.

I know these are generic answers, but I hope they at least point you in the right direction.

Greetings from México.


BTW: if you want to see what I have done following the steps described here, take a look at the beta of my site in Punto flotante.

Quote:
I don't think there will ever be such a thing as "an un-biased review", but a feature/activity/support/developer philosophy matrix would be really useful.

As far as evaluation is concerned, you should check out Scott Goodwin's OpenSourceCMS.com. It will save you tons of time in your evaluation process (at least of OpenSource CMS solutions), since you don't have to spend an hour on the installation step for each product you're evaluating. It rarely has the absolute latest releases, but they're reasonably up-to-date, and give a good idea of what the product is capable of.

You're right, though, that if you've got a custom problem, no solution is likely to do everything you want right out of the box. Thankfully, most CMS systems like XOOPS have the ability to extend functionality through modules/plug-ins. If you need a custom functionality not provided by the core product, see if anyone else has written a module to do what you want. If not, you can always make on yourself without having to rewrite the product code.

Didnt know about that..seems like a nice solution for sites where security isnt a major concern. THANKS

If you do I hope you consider sharing it here..I would also like that. I undesrtand there may be security concerns and all that, but if amazon remembers my login name (among others) my hobby site can also...

Thanks

As someone already mentioned there is a VERY SIMPLE hack that can be found on Koundanshi's Board. I installed it on many different XOOPS sites - it seems to work well. The password is encrypted in a cookie so obviously the user would need to have the ability to rec cookies for it to work.

Just my couple-a-cents

Gnik

Here's how I handle user authentication on my non XOOPS sites. When a user logs in, I write an md5 sum of microtime concatenated with a site specific secret string to the database entry for the user and to a cookie. This is guaranteed to be a unique key. When the user comes back, I use that key to look them up. No encrypting of any user info needs to be done so nothing to crack on the workstation. However, like any other cookie, they can be stolen if someone has access to their local machine.

I will be hacking this into XOOPS when version 1 comes out if they haven't already fixed it. All this talk about cookies being a lack of security is over rated. Almost every major site on the internet has an option to auto login users. With all of the other security holes in operating systems, cookies are the least of our problems.

Chris