Everyone wants to know what their constituency thinks. Some notes on XOOPS modules for surveys with an emphasis on the one I deployed. I will answer questions posted to this thread and upkeep my latest notes on Surveys on my website (this post is based on that).

There are a few options for Surveys. Yes, you can use polls, but those are very simple surveys and don't meet the needs of many surveys. The best open-source survey toolset I've found out there is LimeSurvey (formerly phpSurveyor). For XOOPS, I've found:

* Survey (aka bmsurvey) by Blue-Moon - v0.97 (Note: Bluemoon website dead)
* Survey (by Mithrandir) - v0.6 (old beta, unfinished/abandoned, based on Liaise, a Contact Us module)
* Formulize (Note: Visit developer page for latest edition)
* Xoops Polls/Survey Modules

Both these listed survey modules don't allow changes once the survey is active as they create individual tables for it. Neither allows for branching nor other advanced features that LimeSurvey has.

I'll note that Formulize is better but the learning curve is high compared to other modules as it's an application development framework in it's own right. Also, you could be looking for Contact Us modules which can also do the same thing for simple forms.

The best survey module overall for XOOPS seems to be Survey by Bluemoon (website defunct). It's based upon phpESP (php Easy Survey Package). These notes focus on the Survey module by Bluemoon as it's the most robust overall at this point.

Features
* 10 Question Types: Yes/No, Text Field, Text Area, Radio Buttons, Checkboxes, Dropdown, Rate (1-10, none, not defaulted), Date (no selector), Number (integer or real), File upload
* Informational Fields: allows HTML but not xCode or smilies
* "Other" Field - fill-in-the-blank responses (for Radio Buttons, Checkboxes); remembers (but doesn't display) for Dropdown, Ratings
* Multi-page (definable page breaks)
* File uploads
* Database storage
* Reports: simple, cross-tab
* Test mode
* Archive (de-activate)
* Purge/Delete data (not all though)
* Cloning (of surveys or questions)
* Themes (see admin help and /modules/bmsurvey/examples/classes.html)
* Data exporting (CSV)
* Backup - to Previous Pages/Answers (logins required)
* Save/Restore survey session (logins required)
* Response Limiting (if requiring login)

Features I Haven't Figured out yet
* Email Surveys - allows emailing un/registered users
* Bulk Upload of unregistered users (tab-delimited only) - couldn't figure out how/where

Oft-Requested but not available
* Branching (changing questions based on previous answers)

Notes
Installation is like any other module. Upgrades, per instructions, may require some special actions. I had no remaining existing installations of previous versions to try it on. YMMV.

Uploaded files are stored in the /uploads directory as username_xx_originalfilename.ext. Moving that required hard-coding.

Testing a survey (in admin) requires that it be put into test mode, which, similar to active mode, no longer allows changes to the survey. In my testing, I was able to make some changes. I'm unsure as to what isn't available. YMMV.

Deleting/Purging of surveys is available via a "hidden" function (according to the Admin FAQs) but is available in the Change Status area.

Bugs/Defects

T_STRING Errors
English language file main.php is missing a quote on line 137 that causes an error. I didn't check the other languages included (french and japanese).

Purge file admin/include/where/purge.inc requires fixing a couple of definitions (missing underscores): lines 33, 90.

Purging Data Doesn't
When purging a survey, not all data for the survey is actually removed. It does removes the survey definition info and its related question info (including choices for choice questions), but not the other response data nor access permissions.

Enhancement Requests

Group/User Display in Admin
In various locations (including selecting a survey to edit, or to purge), it shows the Group and Owner (user) by ID instead of name. It would be better to show username and group name.

No MultiSelect Field
There is no multiselect box. Check Boxes can fulfill this, but users may like it.

Date Selector
There is no date selector available. It can be integrated, but....

Link to Module Admin Home
There isn't a link back to the module's administrative home once the administrator gets into the Survey Management aspects.

Final Thoughts
Overall a good usable module. For my installations, I made copious changes to the language files and templates. Used on XOOPS 2.4.5 with PHP 5.2.

Yes, they've all been hacked including the default one with XOOPS as well as the reCAPTCHA hack for XOOPS. The reason that I use reCAPTCHA is because it's the only one I've found that works for people of disability (particularly sight) which is a requirement for most of the sites I work on. The other alternatives suggested, including the new reCAPTCHA versions, require somebody who isn't sight disabled.

We'll see how Barry's 2-step registration tip goes for now (none new since implemented yesterday) and I'll look at implementing the StopForumSpam piece in the future because I'd like to have a single-page registration solution for users.

We're also using it on the xForms contact us module but they don't seem to be using that yet. I must admit I found it interesting that somehow these folks have setup scripts that allow somebody in some other country to sit at a computer screen and "solve" these reCAPTCHAs for their spam bots at $0.05 each.

And no matter how hard one might try, it's pretty hard to keep folks from figuring out that you're running a XOOPS site. Besides changing code in every template and using the xoRewriteModule to change all the URLs, there are a number of other signatures that would be difficult and/or time-consuming at best to remove.

I've just released a community site on XOOPS and we're beginning to see a large number of spam bot and automated mass registrations. Another site on an older version of XOOPS has the same problem (without Profile module). I'd implemented reCAPTCHA but that didn't stop it either. And I was having similar problems with the XOOPS CAPTCHA system as well. And I needed to use reCAPTCHA because of a disability requirement.

It does appear that the spammers and blackhats have come up with methods to get around reCAPTCHA. I've found references to both programmatic methods as well as paying somebody in some foreign country $0.05/submission ($5/100).

I've found several other discussion here on X.o about spammer registrations and posts, and today, wishcraft announced the new Profile 1.68, which I'll have to try out as well, but it's focus appears to be more on invitations and such.

I've seen a few solutions proposed including the hidden field (not to easy since both the XOOPS register as well as the Profile Module use XOOPS Forms instead of presenting through Smarty which would make it easier to target) but also still requires either special programming, and or human intervention and review, as well as special fields with math or other text identification. I've also seen people that block by IP, country, and such (but we can't do that).

However, one possible method I found comes from Stop Forum Spam, and could be integrated into the Profile module to check registrations against an RBL (and perhaps give a success message but not actually add it to the database, or add it but then add it to a special Spammers group). We could even add a link that allows admins to report spammers into this block-list.

Has anyone tried this method? I'm putting it on my list to try it, but I've got too much on my plate at the moment.

I've also found using Akismet and Defensio to help stop it (from Rob Mason on how to code to stop spam).

And I found Xortify which is somehow tied to StopForumSpam, but will have to research it further as well (and it appears to be only good for XOOPS 2.5.x which I've not yet adopted).

Like others suggested, we're adding users to a Spammer group without user rights on the system (to help keep them from coming back), but then we'll have too many folks in the database and to be able to send an occasional system message may be problematic. We've also moved to a 2-page registration, but will see how much that actually helps.

Anyhoos, still working on those bloody b*stards.

OVERVIEW
=========
I wanted to review latest modules for Contact Us functionality and related forms tools for gathering and managing incoming messages and/or uploaded files. It had been too long since last reviewing this functionality. I have been using Liaise 1.26 for several years (2.0.x to 2.4.5 as of this writing) but hadn't tried Liaise 1.27 yet (incorporating Captcha), but I saw reports of problems with XOOPS 2.4.x and whether or not development for Liaise would continue so decided to look around. I'll also note that some of these modules allow for XOOPS captcha usage, but I've heard that has been hacked (still true?). However, there is a community hack to replace it with reCAPTCHA. Finally, I did not review Formulize which is probably the most feature rich forms toolset (and I've used it on a site to great success), but was looking for something else that was quick install and/or setup for non-technical website maintainers.

XOOPS Verison Tested: 2.4.5 using zetagensis theme

Reviewed:
- AM Contact 0.08
- Contact 1.7
- Contact Center 0.93
- Formulaire 3.33
- Lawsuit 1.11
- Liaise 1.27
- xForms 1.2
Not reviewed:
- Contact Plus (based on original XOOPS contact module, but years old)
- irtibat From (based on Contact Plus form code, years old)
- ContactUS with Googlemap 0.1a (never found this)


QUICK REVIEWS
==============

Note: these reviews are quick and not exhaustive, but offered in the hopes that someone else finds the info useful.

AM Contact
AM Contact is a very simple contact us form with just one form and a few other options. The form consists of name (uname or real name), email, subject, text, all required fields. It only sends to the XOOPS Admin email address. You may specify which anti-spam measure to use: None, Q&A (your own), XOOPS Captcha, an image captcha built into the module, or reCaptcha. If this is all you need, it's simple quick and easy. The author recently indicated they will continue this module.

Contact
Contact is also a very simple contact us form with just one form. For administration, you only have preferences. But, you can turn on/off the request of other info: address, url, icq, company, location, comments (rename fields in language files if desired), none required. You can also have one set of check boxes, allow users to get cc'd, specify different SendTo emails (displayed via function/subject), and use the XOOPS captcha. Required fields don't display such (zetagenesis theme). Works. Reasonably active development.

Contact Center
Contact Center allows for highly configurable forms and the ability to store information into the database (none, logging or all form data). Forms are built using a text-based data definition language (similar to a wiki style). Not too hard, but requires you to read and learn a new language. The form intro can be plain text or HTML and has some templating capabilities. Messages may be sent to a group or a registered user. There are access/usage permissions, but you must be a module admin to be able to view data in the database. There are many additional options and custom capabilities including value verification via regular expressions (regex). Interestingly, the module allows for comments. Form submissions require a user to review their form submission and then confirm it with another button press making it at least a 2-click form submission (I didn't find an option to change that). There are some nice screens showing messages sent (by the user) as well as admin screens on the user side for seeing messages info in tabular form (by generic date ranges), downloading the info in CSV format, and via defined status. This module could be used for a simple help desk function as well as many others. Note: there are some spurious menu items showing up in the admin interface - I expect this is due to using a duplicated admin menu function (or something like that, as I've run into this before). In short, a robust module that could likely be useful to users willing to take the time to learn it. I know I could find use of it if the module allowed for permission based access to the results of certain forms but not others. There doesn't appear to be any Captcha style capability. Still under development, but not found in the XOOPS module repository.

Formulaire
Similar to Liaise, Formulaire allows one to build custom forms and list the forms on the site and assign access permissions by form. Submitted form information is stored in a database and can be exported and cleared, and displayed - at least to administrators (and only partial data). Formulaire gives a weird error message when trying to modify the form elements but then allows modification. Formulaire could also be used for polls and allows limiting the number of entries/day (presumably by user and/or IP). You can specify an individual email address (haven't tested multiple) as well as send to one or more groups and a number of options related to who gets what. I'm not sure if this one remains in development or not, but it appears to haven't been updated in a long time. No captcha.

Lawsuit
see separate review. Ad-hoc WYSIWYG pages and customizable forms.

Liaise
Liaise 1.27 add reCaptcha and GIJoe's security tokens class to the forms, but was released by a different author. See my notes on Liaise 1.26. xForms has picked up where Liaise left off. Liaise was released by BrandyCoke which hasn't been available as a website for a couple of years; apparently abandoned.

xForms
xForms is obviously based on Liaise (seems to be 1.26) and can also import forms from Liaise. And like Liaise, is designed to send to groups of users or the site admin email (making it harder to use generic email addresses behind the forms and managing it that way). It provides all the functionality of Liaise but adds captcha (for anonymous users - the assumption being that logged in users are already tested to be human).


CONCLUSION
==========

I ended up deciding to use xForms, and potentially will use Contact Center, but I think it will have a bigger learning curve. I also applied the XOOPS reCAPTCHA hack.

I found this topic while I was trying to figure out how to do custom templates for the system_redirect.html template.

Short story:

To use custom templates in a theme (<xoops>/themes/mytheme/modules/<modname>/<template_name.html>), you must set the template set to Default in the System General Preferences. If using custom templates, theme templates will never be used.

The code for selecting templates is in <xoops>/class/smarty/xoops_plugins/resource.db.php in the function smarty_resource_db_tplinfo and the logic for retrieving a template generally goes like this:
1. If custom template set selected, see if template exists in that set, if it does, return it; else
2. Retrieve the template from the Default set from the database,
3. If the template doesn't exist in the Default set, return false; else
4. Check if template exists in current theme, if not, use the one found in the module templates directory
5. If that doesn't exist, use the one found in the Default set.

I would think that theme templates should over-ride database/file templates no matter what is set as a template set in the preferences. I would suggest logic more like this:

1. If exists, use theme template; else
2. If selected and exists, use template from custom theme set; else
3. If exists, use template from Default theme set; else
4. If exists, use template from module templates directory; else
5. Return false (failure)

Finally, the class/theme.php resourcePath function referenced in this thread won't deal with $path values that start with a full URL starting with http or https (other than pass it back as is), nor does it use the theme-defined template on the admin side (although I don't personally want it to do so for a number of reasons).

XOOPS 2.4.5 on PHP 5.2.14 running CentOS 5.5 with cPanel (Linux 2.6.18-028stab070.2-ent)

@kris_fr:

Should I assume that means it was just FCKeditor 2.6.6 updated, but not any of the other aspects I've noted? Just curious. I think that it should support theme CSS out of the box, and the PHP protection should be turned on, and the FCKUPLOAD_DISABLED should be in there, HTML Special Characters, and maybe a few others things (for instance the image manager is available to anonymous users out of the box, a security problem IMHO).

Anyhoos, would be happy to work with you on getting the right things for others to use. I'll be applying these similar things to CKeditor when I head that direction, but it's all j-script, so will need some additional time to go through it all and get it set right and to find and configure the right image/file managers (and maybe others as well from Burning).

I have what you sent me in May 2009, (for XOOPS 2.3.2b with FCKeditor 2.6.4) still sitting waiting on me. Any changes since then? It hasn't been on my hotlist because no one I work with has needed them -- yet. Most use YouTube instead which FCKeditor already does. But it could be added, I suppose. Do they use the custom module configurations?

My email address is in my profile if you have an update.

I could package it all up and hand it back to phppp to incorporate.

Notes on FCKeditor 2.6.6 (the latest as of this writing) integration in XOOPS as based on that released in the extra editors release of 2009-10. Feel free to see my notes on FCKeditor for XOOPS on my website for better formatting (and where I will make any updates). I also last wrote about FCKeditor using 2.6.3 for XOOPS 2.3.x and previously 2.0.x.

Latest XOOPSified Version: 2.6.4.1 (Included in extra XOOPSeditors release date 2009-10-26)
Latest FCKeditor Release: 2.6.6

This release of the FCKeditor for XOOPS is much better than before generally making upgrades of FCKeditor much easier (some mods still needed, see below). And some integration issues and bugs were fixed and others not. Finally, note that FCKeditor's lifespan is limited and CKeditor is the future direction and I'll be focusing on that shortly for my projects, but there are a bit of changes that must be handled to dial it in for my projects and not all modules are fully supporting it yet.

This edition integrates the ImageManager plugin to replace the built-in version using File Manager, a more robust toolset with thumbnail images, deleting and such. However, you can't disable it on a module-by-module basis as you could before, so you may need to disable it altogether. Because the future direction is with CKeditor, I'll be focusing there generally in the future, but CKeditor requires a plugin for any uploadable aspects and/or the for-pay CKfinder.

Note: all path/file references in this article, generally, will be from xRoot/class/xoopseditors/fckeditor directory.

------------
Installation
------------
New
Extract the FCKeditor from the extra XOOPSeditors release and place it in xRoot/class/xoopseditors/ directory. Feel free to use as is, or customize as I've outlined below. I did that, uploaded the latest FCKeditor release (keeping the ImageManager plugin in the XOOPS version) on top and then made these edits/changes below.

Upgrades
It's always best before upgrading to save your configuration, style, and template files:

FCKeditor Configurations, Styles and Templates
- If you made customizations per my notes, you will need to merge these files: fckconfig-xoops.js, fckstyles-xoops.xml, and fcktemplates-xoops.xml (older versions of XOOPS FCKeditor may require a move of these files)
FCKeditor Connector Configs
- save the config.php file (in ./fckeditor/editor/filemanager/connectors/php directory) to refer to when updating your configs there
- Make appropriate configuration changes as described in my modifications below (or use my latest release)

Note: upgrades from FCKeditor 2.4.x and prior will require making all configuration changes again as described below due to the changes in file structure to FCKeditor.

-------------
Configuration
-------------
Make the following changes as desired:
Custom Configurations
This installation automatically uses the fckconfig-xoops.js custom configuration file (if it exists, it should). Make site-wide configuration changes there as desired. Note: when making configuration file modifications you will have to clear the XOOPS cache to see it because XOOPS/FCKeditor writes a cached configuration file (module by module) there.
FileManager (PHP-based) Modifications
The integrators setup image management (using the Image Manager plugin), but not file management (such as Flash, Media, Files as well as Images). You'll have to edit some files to make that work correctly. See below for other useful modifications (apply as desired)
Module Specific Customizations
Copy the files from the modules directory into the directory of the module you want to modify its storage. This ONLY works for the filemanager and NOT for the Image Manager plugin (it's handled differently). It also requires different code in the connector configuration: if (!defined("XOOPS_FCK_FOLDER") || !$uploadPath = preg_replace("/[^a-z0-9_\-\/]/i", "", XOOPS_FCK_FOLDER) ) { $uploadPath = "content"; } for it to work.

-------------
Modifications
-------------
These are the modifications I've made based on the XOOPS FCKeditor 2.6.4.1 release (includes Image Manager plugin).

Files
The list of files I've modified/added:
- fckconfig-xoops.js (custom FCKeditor configs)
- fckeditor/editor
- o dialog/fck_paste.html (Paste from Word Remove Styles checkbox checked by default)
- o filemanager/connectors/php
- o + commands.php (custom directory/filename code)
- o + config.php (default upload directory, enable Subdirectories, disable QuickUpload, enable ProtectedSource, directory/file permissions, custom directories/filenames, reg user check)
- o + upload.php (disable upload code)
- o lang/en.js (per my desires)
- o plugins/ImageManager/config.inc.php (reg user check)
- fckstyles-xoops.xml (custom css styles for dropdowns -- styles specified in theme css)
- fcktemplates-xoops.xml (custom site templates -- styles specified in theme css)
- formfckeditor.php (use theme stylesheets in editor)
- modules
- o fckeditor.config.js (cleared customizations)
- o readme.txt (clearer instructions)

Use Theme Stylesheets in Editor
This allows your editors to see what it will actually look like while editing. In ./formfckeditor.php add after line 86:

Enable ProtectedSource
This security issue should have been done by the development team IMHO since this configuration depends upon which server-side application language is in use (php for XOOPS), so, to stop having to worry about this, put in in fckconfig-xoops.js (at least until this gets fixed):

Allow File Manager Browse / Uploads
The default installation has a new Image Manager integrated, but that doesn't deal with files, flash and such. Edit ./fckeditor/editor/filemanager/connectors/php/config.php, after the global $Config statement add this code (comes from the XOOPS 1.2.1 editors release (circa 2005) with a couple of modifications (relative URLs, sub-directories, registered user):
Note that code checks to make sure the user is a registered user (no anonymous users). Also edit these lines:
Using this, the default upload directory is thus /uploads/dirname. To change the second part, change 'content' to the directory name of your choice (like 'mynewdirname'). Whatever you name this, it remains a subdirectory in the uploads directory.

HTML Special Characters Issue
For whatever reason, this error still persists. XoopsEditor 1.21 solved it by getting rid of the undoHtmlSpecialChars call in formfckeditor.php (as introduced in the XoopsEditor 1.10 release). However, it was re-introduced. I expect there is a reason that this call is made by FCKeditor for some sort of protection in case someone adds a special character in the source side - ::shrug::

Using any special characters cause an unintended cascading effect of ampersand conversion. For instance, a quote " will become &quot; in the code — as it should be. However, after FCKeditor retrieves it from the database and displays it, it becomes &quot; in the WYSIWYG instead of ". The next time it becomes &amp;quot; and then &amp;amp;quot; ad infinitum. What I had to do was change fckeditor_php4.php and fckeditor_php5.php, approximately line 158 to (in function CreateHtml):
This is because this XOOPS implementation uses the $myts->undoHtmlSpecialChars function before throwing it back into the database so we need to use the XOOPS version of the htmlspecialchars function.

Upload File Permissions
Files and folders will be created with 777 permissions unless you change it in the configurations file, change in fckeditor/editor/filemanager/connectors/php/config.php:

- Files: line 100 (recommend 644)
- Folders: line 104 (recommend 755)

File Uploader Doesn't Check if Disabled in Module Configurations
Interestingly, in the module-specific configuration code, there is ability to disable file uploads for that module alone, but the code doesn't exist to actually disable upload ability in the php connector. To do so, add these lines to fckeditor/editor/filemanager/connectors/php/config.php (before enabling -- i did it starting at line 62):

Paste from Word Remove Styles Checkbox
I want the remove styles checkbox checked by default for the Paste from Word function, so made this change to line 339 of fckeditor/editor/dialog/fck_paste.html:

Require Registered User
Both the Image Manager and File Manager should require at least registered user access. yeah, that means anonymous users can't browse the files. So what. Do you really want them having access to this? Because if they can upload files using this, then you're in trouble. To fix that in Image Manager, change line 26 to (Filemanager is fixed in the code above):

User Directory and Filename Patterns
The directory (by month/year or year) and filename (various options) patterns was introduced in XOOPSeditor 1.2.1 but dropped in this implementation for some reason (I'm assuming to touch as little of the connector code as possible for future updates). Some of my community sites liked it, so I've added it back in. To add it back in, follow these instructions.

Add to fckeditor/editor/filemanager/connectors/php/config.php the following lines:
and then make configuration changes based upon the pattern(s) you want to use.

In fckeditor/editor/filemanager/connectors/php/commands.php remove lines 177-179:

then, add starting at (before) new line 182


-----------
Other Notes
-----------
Image Manager Not Disabled
This installation doesn't allow for the disabling of the Image Manager if it's specified in the configuration file. It might be best to setup module specific configurations in the fckeditor/modules directory and control it from there. That may be a future direction, but for now you'll just have to remove it from the editor configs.

Safe Mode / Image Manager
If you are using safe_mode = On, then you will need to edit the Image Manager plugin configuration file for safe mode.

ImageMagick or NetPBM
Image Manager uses GD by default, but if you want to use ImageMagick or NetPBM, edit the Image Manager plugin configuration file.

Certainly post here if you have questions or issues; I'll be monitoring this thread.

Thanks for the response trabis!

trabis wrote:Quote:If I understand, should I decide to use the 3.41 (non-xoops244-ified) versions, then I should use the pre-/post-check code per the instructions (I'd disabled those for the moment while doing some integration and regression testing, so will re-enable them). And I don't mind hacking mainfile. I use the xoRewriteModule, too.

Quote:Understood. I'd suggest changing hosting providers since it's easy and cheap to find, but I also understand providing a solution for those who are constrained to using inherently insecure setups.

Quote:I'm obviously a touch dense. Thanks for the clarification.

What I heard:
= If you can have a true trust path outside root, use whatever GIJoe version of Protector you want, but include the pre-/post-check code in mainfile.
= If you must have xoops_lib and trust path inside the doc root, use the module 3.40x as included with the XOOPS release.

Thanks again!

Yeah, I'd done a DIFF of the 3.40 and 3.40x versions and didn't see much that said I needed to use 3.40x over 3.41. Since 3.41 is working fine, I don't see any real reason to use an older and customized version of Protector module (or any others for that matter).

I also don't understand why we would want to use a hacked version of a module that is constantly under development. Are we working with GIJoe to make the appropriate changes in the Protector module to work with all versions of XOOPS?

Because the web is filled with dangerous crocodiles (script kiddiez and worse), we want to be able to keep our sites protected as best as possible and protect against the latest exploits. Since the Protector releases aren't synchronized with the XOOPS releases, it doesn't make sense to leave XOOPS installs vulnerable to the latest exploits requiring users to use hacks and do diffs and such. Also, the latest info I've read is that the preload aspects used in the 2.4.x and 2.5.x series (with an end-of-life in 2.6.x series) may be dropped or changed altogether.

So, again, I'm trying to understand the purpose of the hacks, not the fact that it didn't change anything.

I guess the real question is: What do they ADD or do that is better than 3.40 or 3.41?