Thank you both for your responses.

First off, our lan is 100 megabits per second and bandwidth isn't my problem. I guess using "page draws" in my original post was a little confusing. My biggest problem is how "snappy" the pages are when generated. In other words, how long my server spends gathering information for drawing the page before the page can be delivered to the user.

I believe that the raid is hardware based (I haven't maintained the hardware on it, so I'm going from memory here). I think think the OS is NT 4 (I know, we need to upgrade). Other processes are relegated to print queues -- nothing much else.

As far as software configuration, I simply performed a standard Xampp installation. This package installed PHP, Apache, and MySql for me. I have done no optimization to it (and am not really trained in such skills). XOOPS is caching the html templates, but I'm not sure about any module-specific caching that should/could be used.

I ran the PHP-MyAdmin function that you mentioned in your note. The results are available in PDF form, if you care to take a look. It appears as though 85% of my queries are select related, while the rest primarily update the database.

Again, I believe my problems lie with module code in that it can simply require a large number of queries (select) to gather information for page generation. As a side note, the draw times are significantly faster for me than others in my area since I am designated as a "web master". I poked around and have noticed that a lot of security code is simply bypassed if the page is being generated for a web-master. This works technically, but in terms of performance, I never really see the hit that other 'normal' users see. So I'm been caught off guard a few times when people complain about the performance of the site and I think that everything is just fine.

I guess what it all boils down to is a recommendation on either software and/or hardware optimization that can influence this type of behavior positively. I'm willing to spend some money in order to get it faster and I'd kind of like to hear from people who maybe have been through this scenario before themselves.

Thanks again for you input...

This question may not be in the right place, but...

I am responsible for an intranet server running a XOOPS installation for a department within a fortune 500 company. The XOOPS software seems to work well, but is slow. This hasn't been too much of a problem up till now because of the type of usage that have targeted for our site (downloads, forums, etc.). We would like, however, to ramp up usage with work flow tracking (zenTrack) and other in-house developed modules. The idea is that we have ~100 departmental employees (say 20% on at any one time) that would use the site throughout the day with, say, and additional 5 top 10 users at any time from outside the department browsing the site.

Our existing setup is comprised of an old ~1 Ghz Pentium 3 server (I know, but at least it has 2 cpus inside of it) running against a raid with several IDE drives hooked into it. Nothing terribly fancy and seriously outdated.

The site, today, can take many seconds to generate particular pages, presumably due to the number of SQL queries that are being run for proper page generation.

So here's my question, what type of hardware would you suggest for replacing this old beast? Cost isn't so much an issue (lets say a top end of $20 thousand), but performance when this project is complete is important. I'd hate to spend money like that and still have each user wait 5 and 10 seconds to get page draws -- even if the site can handle many users at the same time.

So what do you all think? High end server with high-end SCSI raid? Separate out the servers into a multi-tier situation? What types of setups do you run on your intranets and do they meet your needs? Any and all comments are very welcome and thanks in advance!

--robert lankford

I've been trying to apply this hack (https://sourceforge.net/tracker/index.php?func=detail&aid=1314038&group_id=41586&atid=430842) to a vanilla XOOPS 2.2.3 final installation.

The code authenticates my login, but then tries to "load XOOPS User database datas". At this point, the $getUser count is 0, which reverses the authentication.

Does this mean that this hack, unlike the old one for the XOOPS version 2.0.x branch, doesn't include the ability to create a new account in XOOPS automatically if the login was LDAP authenticated?

If that doesn't happen, then here's my vote for putting that feature back in! I'd hate to have everyone go through the register process for my site again!

Thanks for everything you do...

Well, guess what? It was a browser issue!

I ended up completely removing the forum and installing it again on my site. Trying to add a moderator still didn't work!

I then tried it in Internet Explorer -- presto! Now it works.

So, in summary:

IE 6: Good

Firefox 1.5: Bad

Well, good and bad in this single example anyway ;)

Thanks everyone for taking the time to look though...

Quote:

Yeah, I don't think that's happening for me. Unfortunately, the site is at work behind the firewall, so I can't fiddle with it now. Do you think it could be a browser issue? I use Firefox. Maybe I should try this in IE?

...of course, I'm just stabbing in the dark now...

Thanks for the response!

I am using XOOPS 2.0.13.2 & CBB 3.01.

I cannot add anybody as a moderator to my forums from the Edit Forum administrator screen. I have close to 400 members on my site. I click the 'list' button under moderators. I select one or more people from the list and click 'add'. Nothing happens!

Does anyone else have this problem or have any idea on how I can fix it?

Thanks in advance...

I'm still on the 2.0.xx branch of Xoops. I'm currently using the forum that came with the XOOPS install. I would like a more fully-featured forum that supports the following:

- Notifications
- Attachments
- Better-than-the-default image inclusions
- High feature text editor

What's the best forum out there at the moment? Is there a better forum for the 2.2.xx branch? If so, what is it called?

If there isn't a forum that meets these needs today, will there be one later that should do all this?

Thanks in advance for your time, analysis, and opinion...

Hi,

What he means is, you need to use a tool, like phpMyAdmin to edit the MySQL database that stores the data driving your XOOPS website. Although the GUI has been hosed by your selection of LDAP Authentication, you can remedy that situation by finding that field in the MySQL database that was changed from 'xoops' to 'ldap' and switching it back manually.

And just in case you don't know, phpMyAdmin is a php-based GUI that acts as a database editor of sorts for your MySQL database. So download it, install it into your htdocs directory, configure it for root access and make the change by running it in your browser. Then remove it! You don't want just anyone coming by your site to be able to phpMyAdmin into it with root access.

First off, I very much appreciate the effort to add LDAP authentication directly to the XOOPS core!

My site (2.0.12) currently uses the authentication hack to perform LDAP authentication. I've installed 2.2.1 on a test machine and have configured it to attach to my LDAP server.

Here's my problem, it looks as though I am authenticating, but since my corporate account hasn't technically been created on the new site, it am getting a login error (after successfully authenticating).

The authentication hack would automatically create the new account whenever a new corporate user gets successfully authenticated against the LDAP server. But XOOPS 2.2.1 seems to have dropped that from it's implementation. Is this correct?

If so, what about passwords? If a user registers at my site, but uses the corporate LDAP server to authenticate, what happens when the user changes the LDAP server's password? They won't have also updated their password on my site. Does that mean that they'll authenticate, but still can't log in?

Let me finish this note by stating that corporate users really don't care about their accounts on the network. Using a XOOPS site should be transparent to them since their account/password is already handled elsewhere. Is it possible to update the 2.2.1 code to change the LDAP behavior to 1) create/activate accounts automatically for LDAP authenticated users and to 2) ignore the current XOOPS password for LDAP authenticated users?

Thanks in advance, and thanks for the great work.

Well, I found the problem myself.

It appears that in the file "include\comment_view.php", there is a section of code that looks like this:

Quote:

Some of my site's members had a umode of nothing. In other words, $com_mode became an empty string. This doesn't work with the common template code that people insert in order to display comments:

Quote:

As you can see, a $comment_mode equal to the empty string will cause no comments to be displayed. So, to correct the issue on my site, I've added a single line to the code above:

Quote:

So now if the umode returns nothing, the $com_mode variable gets the default XOOPS setting instead.

--------------------------

I won't include this as a bug fix because I don't know that I've fixed the bug. Umode, for all I know, maybe shouldn't ever return an empty string. In that case, the code that generates the umode variable should be checked. Other than that, however, this hack seems to work just fine for me.