Adding links is yucky, reordering them is easy.

Go to your module administration page (where you add and remove modules) and change the weight of the various modules. Heavier modules go lower, lighter ones go higher.

I'm looking at line 34 of newbb/include/search.inc.php, where it makes an SQL query. If you look at the end, where it says WHERE f.forum_type=0 might be it checking if the forum is protected.



You might try adding a quick fix to disable that



But don't take my word for it, and be ready to change it back if it doesn't work.

Put this around line 77 of register.php

This is an ugly topic, in my own experience trying to create CMSs, effectively banning people is extremely difficult. For example, most of my visitors are using dailup service, which makes it impossible to ban them by IP address, as you'll just wind up intermittantly banning other people, I couldn't ban IP ranges without locking out huge parts of my user base. The best solution I ever came up with was to set cookies that make people banned, but anyone with a reasonable grasp of internet technology could get around that one.

Banning people is hard.

Just another quick thought, it relies on gzip compression, which could be a problem, does anyone know of any other broadly supported/used compression systems?

Basically what it does is pass along the field names of the form in a compressed hidden field (for some reason IE won't pass that along except as POST, but maybe somebody else could figure that out), then it will do one of several things, and load the result into a class variable called found_results. All of this comes after calling $gt_form->get_results().

on a field that allows multiple select, it will check for the names of the checkboxes or listbox entries and load all the ones that are found into an array. i.e. if you have a field of checkboxes called "expressions" with the fields "smile" "frown" and "grimace", and select "smile" and "grimace", the recieving page will look for POST['expressions_smile'] = on, POST['expressions_frown'] = on and POST['expressions_grimace'] = on, and find that you have selected smile and frown, and add $this->found_data['expressions'][] = 'smile' and $this->found_data['expressions'][] = 'grimace'. If it finds post input that doesn't fit into the fields defined it will either ignore it, or if it were, for instance, a radio button value that isn't listed, return false.

It can also pull the options multiple selection fields from a seperate file, which currently uses my gt_data flat file data storage/retrieval class, but I think that could be changed pretty easily.

Another feature it has, that might not be so useful, is a function to sort the results into a multidimensional array. By calling for instance:


Would make an array $sorted_results containing two keys 'uinfo' and 'otherinfo', 'uinfo' holding 'uname' 'password' and 'home', and 'otherinfo' holding any other submitted fields.

Right now I'm still fixing it up a little, like making it at least assign a placeholder to empty fields, instead of just not setting them.

I'll put the code of some of my other classes online sometime in the next few days, I have a whole section of my website devoted to them . here

Define the message as a constant in the language files of the two languages you want, then call that constant from the module.

I've created a class for the creation of forms and the validation of submitted data. Maybe that could help.

What it does is let you define a form item from an array where you say what kind of input, what responses can be allowed (for text). It also lets you do multiple choice responses of various types (checkboxs, listbox, radio buttons, the works). I think it might be useful here because it automagically sorts form values into an array and
people could add about 6 lines of code to their module for each field they want to add.

I have a weak demo of an old version here and the equally out of date source code is here

I'm looking at it some more, and I've revised my opinion to:



I would suggest waiting for some bigwig with a more in depth knowledge of XOOPS to come along and explain how XOOPS stores, retrieves, updates etc. A user's post count. I must admit that I'm now a little curious myself.

I'm working on a new feature for TheaterMan 2.1 that allows you to add a survey to instances. The surveys are very customizable (allpolls.php, which handles everything about creating surveys is currently 1200 lines and 60K, and far from finished) and pretty nice looking too. I'll probably have a working beta in the next two weeks, so if anyone wants to get in on that, let me know.

I'm also probably going to split off the code for surveys and turn it into a totally seperate module. I've noticed a lack of good survey modules, so I'll try to change that. Some people, after all, might want to collect more information than the basic polls module allows.