Is it possible to get a value from $xoopsModuleConfig settings for use within a block? Doesn't seem to work for me.

I apologise in advance if I've missed a simple answer somewhere, but I can't seem to find one.

Sorry if I missed the point, but changing the ampersand (&) in the query string is the only way I know to fix this particular XHTML validation problem.

How to do that when it's autogenerated is another question. One way might be to change PHP's arg_separator, but that may not be possible in a hosted environment. Another possibility might be to use htmlentities(urlencode($data)) where needed in the code.

Change the & in the query string. It should be & amp; (without the space).

( StudioC Please Note )

A solution has been found for the denic.de server problem with .de TLD whois lookups. The fix will be incorporated into the next release of all Netquery editions. For those wishing to patch the current v2.1 version of the XOOPS edition, the code change for Netquery's main index.php file is as follows.

Add after:

This line:

Jeez, two mistakes in one thread. I promise that my code isn't as sloppy as my messages.

@StudioC: Sorry, but the .de whois server is very "secretive" and doesn't seem to cooperate with direct queries on port 43. I haven't yet been able to figure out a workaround myself. If you have downloaded your own copy of netquery and have discovered a way to make that server respond with anything more than a "connect" message, I'd be grateful for your solution.

@JMass: Actually, XOOPS only goes to the XHTML 1.0 Transitional validator. So it's not strictly STRICT. But never mind.

Anyhow, you're right about the tags. (Message error corrected.) I agree that both tables and forms are elements. What puzzles me is that W3C happily validates a table inside a form, but it spits at a form inside a table in most cases.

Oh well, as Michael has noted, I think I've managed to get around the issue in another way. Thanks.

Thanks, ackbarr. Actually, nesting wasn't the key issue as such. I knew that tags must always be nested correctly in all cases.

In this particular case, however, it appears that the layout order has to be <form> <table> </table> </form>. From what I've been able to discover, the <table> <form> </form> </table> order, even 'tho it is also correctly nested, is not valid unless the entire form is contained within a single cell of the table.

Am I missing some different approach with XHTML compliance?

As noted here in an earlier thread, I've been working on making the next release of the Netquery module fully compliant with XML/XSL standards -- or at least consistent with current XOOPS core compliance with XHTML 1.0 Transitional. For anyone interested, a v2.2 pre-release test installation can be seen by clicking the XOOPS Demo button athttp://www.virtech.org/tools/

I've been able to resolve most W3C validation issues, but precise information on the use of tables together with forms seems a bit hard to pin down and I'd be very grateful for any input from you XML gurus out there.

Here's what I think I've discovered so far.

It seems that there are only two ways to get pages fully XML/XHTML validated when using forms together with tables. The first "acceptable" way is to place the whole form entirely within a single cell of the table -- which kinda defeats the entire purpose of using a table in the first place. The second way is to put the table entirely within the form as follows: the initial <form> tag is placed before the <table> tag, then every form <input> (incuding hidden inputs) must be placed within a table cell, and then the </table> and </form> must be closed in that order.

Is that right, or have my searches missed something somewhere that I should have found?

Thank you for the kind words. Much appreciated.

Yes, it's a bit of work, but it's fun too. I need a "retirement hobby", especially here in the depths of the Canadian winter. :)

I have been working recently on making Netquery fully compliant with current CSS and XHTML standards and I've found that the W3C XHTML Strict validator seems to dislike the simultaneous display of multiple forms. More precisely, it objects to multiple instances anywhere on a single page of input fields with the same ID, even when they're in separate forms.

In the circumstances, there appears to be three options. The validator would be satified if we simply elimate those input field ID attributes and rely on input field names alone (deprecated). We could completely revise the PHP script handling of forms posting to accomodate multiple unique IDs for essentially the same input values (e.g., authid). Or we could revise Netquery's user interface so that it displays only one input form at a time rather than displaying all query types at once on the same page.

I am hesitant about the first option. Relying on deprecated attributes never seems like a wise approach and is quite likely to require even more work in the longer term. To me, the second option seems more like a kludge than a real solution and it doesn't appeal to my "neatness" fetish. So, although the last option probably involves the most work in the short term, it may be the best direction to take for a number of reasons -- not least being a simplified user interface, at least in its outward appearance.

I am currently trying out the third option concept in the standalone edition only which can be seen on my test site athttp://www.virtech.org/netquery/ That new XHTML interface approach can be compared to the existing (v2.1) XOOPS module multiform interface athttp://xoops.virtech.org/modules/netquery/

I'd be grateful for any and all opinions and comments that anyone might care to offer. If users (actual and potential) think it's worth pursuing, I'll then take a crack at the CMS editions, including the module for Xoops, of course.

The answer depends on which DSL service provider the original questioner is asking about. They vary widely, especially the upstream bandwidth for residential services which is, as you say, the important issue for running a server. And there are, too, the questions of terms of service and acceptable use policies which also vary widely.

You're not going to get much better downstream bandwidth than 6 mbps (that's megaBITs/second BTW) from any DSL service provider, even with a commercial service. The more important question of upstream bandwidth can only be answered on a case-by-case basis. It requires more information about the telco operation that is involved.

Individual distance from the CO is also an important determinant of whether you get the full rating of any DSL service in either direction. And that means phone line distance, not line of sight or driving distance, which only your own telco knows for sure.

Bottom line: There are too many "ifs" involved to be able to provide one right anwser for everyone and a good answer for any one individual needs more detailed input.