Yup. All three versions that I built (for Xoops, Postnuke and Xaraya) are fully functional modules complete with installer and admin functions. And all have been running with the latest available versions of those CMSs on my test platforms here at work. The major test phase shortcoming has been a lack of *nix platforms -- our work environment being almost entirely WinXP Pro and Win 2003 servers.

But this is a complete "third-party" module, and neither a "hack" nor a "bug fix" for any existing XOOPS module. In fact, the lack of anything similar is one reason I thought it would make a good experiment. So I didn't think my uploading it now to XOOPS Dev directly would be appropriate. Of course, if any of their developers want it, they're as welcome as anyone.

Regards,
Richard

Anyone associated with XOOPS development interested in claiming a "homeless puppy"? :)

I've recently been exploring several CMS possiblities at work, including Xoops, of course. As part of that process, I've developed an identical (more or less) module for each and have now reached the point where I'd like to pass it on to the respective communities for whatever purpose it may possibly serve in the "public domain". My chief problem is that I can't post it for external access on our corporate servers. So it has no home at all.

Here's a brief description from the "online manual" I've included in the package:

Netquery provides users of your site with a range of common network tools, including Whois lookups, DNS queries, ICMP ping, traceroute and server port checking. Each feature can be enabled or disabled individually by the administrator. The administrator can also configure the Whois feature to specify which Whois server is associated with each domain name.ext entry and can add, modify and delete those entries in the Netquery Whois data table.

If anyone's interested, you can claim it as your own handle its public availability in whatever way you wish. (Although I would be interested in any feeedback, the "fame and glory" of authorship concerns me not at all.) Just give me an email addy or an upload destination to pass it along and it's yours.

Regards,
Richard.

My apologies if the team has already picked this up from the Installation Troubleshooting forum, but it seemed important enough to post as a "bug" just to be sure that it gets to the "right people".

It appears that the "Host Abstraction Layer" section of includes/common.php needs a few more refinements to fully accomodate us Mickeysoft folks when using the latest version of PHP ISAPI.

For details and a working solution handed to me by a kind fellow user, please see this forum post.

Regards,
Richard

Ackbarr may have his own thoughts about it, but I think you've located the problem exactly. I don't know where you found it. (I read every post with Xoops+ISAPI that I could find here and via Google.) Wherever it was hiding, that suggested fix works.

One place I didn't look for answers was throughout the XOOPS code itself, but I now see that the programmers have obviously located and commented that $xoopsrequesturi line themselves. For some reason, in the latest XOOPS version, however, their "Host abstraction layer" doesn't quite work with ISAPI. Trying to keep up with Microsoft's quirkiness is never an easy task.

THANK YOU for your help. (Your English seems perfectly OK to me, BTW.) Now I can continue my side-by-side testing on a more even playing field.

Regards,
Richard

With debug mode on (with or without the added line in common.php) it outputs only the following PHP "notice-level" error: Notice [PHP]: Undefined offset: 2 in file F:\VIRtech\XOOPS\include\common.php line 253.

Is it possible that XOOPS is halting on PHP notice-level errors even though PHP itself has been configured to ignore them? Obviously, I'm "reaching" for this one.

BTW, I appreciate very much your taking the time to respond. I'll work with you as long as you think it's worth it, but don't "bust a gut" over one baffled tester.

Thank you. Done as asked. Unfortunately, I don't think the results are going to help us very much.

When XOOPS is running with PHP in CGI mode ALL modules work corectly. In that case, with your suggested addition to common.php, accessing the news module shows the following: /xoops/modules/news/index.php?

When XOOPS is running with PHP in ASAPI mode, however, attempting to access ANY module produces NO output at all except a blank page. The contents of the page are as follows: And the addition to common.php shows nothing extra.

I would tentatively conclude that the error, whatever it may be, is occurring before the process uses that inclusion in common.php. But I must admit that I'm completely baffled by this, especially since the other two beta versions CMSs seem unaffected.

Problem: XOOPS is OK with PHP CGI/FAST CGI but not with PHP ISAPI

Xoops version 2.0.7.1

Test platforms: "Genuine Intel" PCs (P4s with 1 GB RAM)

OS versions:
Windows XP Pro Edition with IIS5
Windows Server 2003 Standard Edition with IIS6

MySQL version 4.0.20d with phpMyAdmin 2.5.7-pl1

PHP version 4.3.8 with "php.ini-recommended" modified as follows:
For evaluation purposes, I am currently running XOOPS along with PostNuke v0.750 and Xaraya v0.9.9 (each with its own MySQL database, of course) on test platforms under two OS/IIS systems as noted above. When using the CGI version of PHP, all three CMSs work perfectly on both platforms. However, when I switch to PHP's ASAPI mode, XOOPS produces errors while the other CMSs continue to function without any problem.

Details of the XOOPS problem are as follows:- The main index.php and login user.php pages remain accessible. I am also able to log on to XOOPS and access the administration admin.php page. When I attempt to access any user module or admin function, however, only a blank page is produced. Setting Xoops' DEBUG option, shows only the following PHP "notice-level" error: Notice [PHP]: Undefined offset: 2 in file F:\VIRtech\XOOPS\include\common.php line 253. A possible "clue", but not much real help there.

Having tried a bit of "searching and fiddling" on my own, I'm hoping that someone else with longer XOOPS experience may be able to offer some more pertinent ideas for a solution. Otherwise, I'm about ready to give it up. Suggestions will be gratefully received.

Regards to all,
Richard

P.S.: I should have mentioned that the IIS server is always restarted between CGI and ISAPI tests. And yes, I have tried the latter both with and without the DLL installed as an ISAPI "filter" for the IIS web service.

The ping-traceroute module that I created for my personal use is very basic -- text output only -- no visual TR. But it should work for either 'nix or windows. If interested, anyone is welcome to it for whatever use it may be.

It can be downloaded HERE

PLEASE NOTE: It employs system calls. So, if you're using it under WinXP after running MS's "Lockdown Tool", it might not work without removing some of the denied permissions on the required \system32 executables.

RV