Thanks, snow and suico. That's helpful info.

Thanks, Bassman; great help! I noticed that style.css and styleNN.css were identical, with the exceptions of some of the changes that I had made to styleNN.css. So, I synched them up, and that solved the problem.

Any idea why there are two files?

I have related questions:

Why do the colors differ between my windows/ie machine and my linux/firefox machine?

More importantly, can I adjust for this within the css stylesheet(s), and if so, where?

Thanks,
Jim

Quote:

Are those identified in the readme PDF(s)? I think I might have deleted that from the server but still have it in the zip file on my PC. I seem to recall moving quite a few files from the module into some of the core folders, so my best answer would be, I think so, but I'll check to make sure.

Quote:

Well, this tells me that I must have something set up incorrectly, which is good info. I hope it's the core files, because that's pretty easy to fix!

Quote:

Validating email addresses is a great feature, but it doesn't quite do everything I need. The membership of this particular web site will be much more restrictive than "have an email address". I guess Reg Codes is the most promising way to go. I was looking for something that would require less for users to remember. (Yes, I anticipate that even a simple code might be a problem with some users!)

I'll let you know if the core files solve the problem.

Thanks,
Jim

I've got a similar problem, but with a much more limited base of knowledge.

I would like to have my users authenticated with something external to XOOPS. I have no experience as a sys admin or anything close to that, so I need to know if it is feasible to set up LDAP on a shared server and then have XOOPS use it for authentication. (I think most xoopsers who want LDAP authentication are putting XOOPS into environments like intranets and extranets where they have their own servers. I can only afford shared hosting for my web sites.

I don't want to constrain my future web presence to using XOOPS only, and I don't want to force my users to register additional user names and passwords if I find more applications that I want to present to them. In other words, not everything is best delivered as a XOOPS module, so I'd like to get as close to a single sign-on as possible.

If XOOPS is set up to use LDAP, does that mean that the XOOPS registration process inserts the right information into LDAP, so that another application could also authenticate against the same LDAP?

If that is the case, then can I start with a fresh XOOPS installation and a fresh LDAP installation? As new opportunities arise in the future for applications other than XOOPS, I can integrate them with the existing LDAP, assuming they have that capability. (That's still a broader opportunity than just waiting for cool new XOOPS mods. I think XOOPS mods are great, but that's expecting too much from them, I think.)

Where should a novice start with all of this?

Thanks,
Jim

Thanks, Julian. Great help.

I'm not sure this next question is a Reg Codes / Formulize question or not:

When I view user profiles, I still see the default XOOPS fields (interests, AIM address, etc.), and I don't see the fields I added.

In the Preferences for Formulize, it seems to indicate that the same form will be used for registration and for viewing and editing accounts. Is there somewhere else that I need to change things so that my new registration fields will show up when viewing and editing accounts?

Also, (Advanced Question) is there a way to configure registration approval so that, as site administrator, I can view the registration data before approving? Currently, I have it set up so that I have to approve new registrations, but all I get is an email with an approval link. I can't go in and see what a user has entered in the registration form before I approve, because when I search for users, I can only see approved users. I need a "purgatory", where I can see user registration info before approving (or denying) them.

Thanks!

Jim

I'm using XoopsPoll version 1 (AFAIK, the latest release, in the repository).

When I edit a poll and change any of the options (responses), I see that they are not saving properly. If I go to the poll on the user side, I generally see some of the options (responses) repeated. If I go to edit the poll again, I generally see that each option has the same value, which is the value I set for the last option (response) in the series. Also, the colors are not showing, but that's less of a problem right now.

Has anyone else had this problem?

I'm creating a multiple choice, so is "allow multiple selection" a known issue?

I should mention that the default poll that comes with the installation is a single option (response) poll, and I have the same problem in Edit mode for that poll. However, it appears fine on the user side.

In other words, there's a big gap between what shows on the Edit screen and what shows on the user screen.

Thanks,
Jim

I'm stuck!

I'm trying the Formulize/Registration Codes approach, because I just want to add a few simple fields to the registration form.

As far as I can tell, I have installed both modules successfully. (I got the "[module] has been installed successfully" message both times. I can use the Admin CP for both modules, but I really don't know how to use them.)

However, now, when I try to register as a new user, I get a prompt for a registration code, followed by "If you do not have a registration code, you can click here to register for a basic account." The "click here" link leads to an error page:

Quote:
1. I only want Reg Codes (at this time) so that I can modify the registration form, not to create any codes. Is it possible to have Reg Codes installed and still have a registration form that does not prompt for a code first?

2. I only want Formulize for the same reason (at this time), so that I can add fields for first name, last name, street address, etc. to my registration form. Do I have to create a new form in the Admin CP for Formulize and somehow then replace or integrate my existing registration form? I just don't know how to proceed.

3. Lastly, the permission issue implied by the error message (quoted above) has me confused. Is there another block or something that I need to look for and give permission to anonymous users?

I might want to use actual registration codes or custom forms in the future, but right now I just need to customize my registration form to capture different information. I'm building a site for a residential community, so we need to know that users actually live in the community.

Thanks,
Jim

Quote:

Well, the zip file unzipped as xoopsgallery 1.3.3.x, and there is/was no xoopsgallery folder inside it. (Yes, I should have listened to that voice in my head that warned me at the time how odd that seemed!) Other than the goofy name, it seems to be the right directory structure. That is, it has the xoops_version.php in it.

Having said that, there's no way for me to remember exactly what the directory structure was when I first had the install problem. But I'm pretty sure it wasn't a "nested" issue. Whatever else happened, I managed to screw it up twice, so that's the level of competency we're talking about here ...

As I mentioned earlier, I tried renaming it to xoopsgallery, but that doesn't help for the two "phantom" modules that are already showing as installed. I'm sure it would help for a new install, but that's not the problem I need to solve.

I appreciate all the help, especially so quickly. As it turns out, I installed an alternative gallery that seems to be working fine, so I really just need to clean up the xoopsgallery stuff. I can easily delete the xoopsgallery folder, but I just have no idea how to uninstall something that clearly wasn't installed properly (twice!).

Based on my newbie intuition, it looks like /modules/system/admin.php must look for the installed and "ready to install" modules in a table somewhere. It's finding two entries that it displays as "installed", but it's obviously not finding the link to the module icon. I think that's why it displays "Module File for Not Found!". And it's not finding the text for the title of the module. For some reason, it seems to be satisfied with what it found, enough to display a row (twice).

In order to get my Modules Administration page to stop displaying the two "phantom" modules, I need some way of changing the information in the tables that is driving the page to display the two bogus rows. I guess I'm not too concerned with the fact that there are two rows: if I knew how to get rid of one, I'd know how to get rid of the other.

Next steps?

Thanks for your continued help,

Jim

Quote:

I didn't delete the folder; sorry if I was unclear.

The problem is that somehow Modules Administration just isn't seeing the folder for the installed "phantoms". It's there. In fact, just to make sure, I deleted it and copied in a fresh one.

Since the folder is in /modules, it's available to install. Unfortunately, "it" (some module, anyway), in phantom form, is already listed twice in the list of installed modules, with no icon and no title and "Module File for Not Found!". It's the phantom modules (which don't really exist but obviously have some table entries somewhere) that I want to "uninstall".

I even tried completing the URL for the uninstall (admin.php) "manually" by typing in the modulename (xoopsgallery), which I can see by hovering over the install icon for it.

One additional note: the name of the folder is not "xoopsgallery". Is that the problem? I didn't change it. It comes from the zip file as xoopsgallery 1.3.3.x, and I'm thinking maybe the folder name is the problem? I also tried manually typing various folder names for the admin.php script to uninstall, but there's also a space in it, which I wasn't quite sure how to handle; %20 didn't work.

Any ideas?

Thanks,
Jim