Hey BJB... I slip away from this forum for months, and then post a half-dozen messages in a day... go figure.

Not sure if this helps, but here's a possible clue...
I too was having somewhat similar problems in the past. What I discovered was that it wasn't my server at all. Instead, the slowness related to external content that I had added to my site. I can't remember specifically what the content was... maybe weather data. When someone would visit my site the page wouldn't load until the external data had been received. As soon as I removed the offending content, the pages loaded very quickly again. Looks like you might have some external content being loaded into your site through affiliate advertising. What happens if you temporarily disable these listings? Does the problem go away?

One other suggestion... since you have root access, you probably have access to your server "access" and "error" logs. I'd take a close look at the error log to see if there are any hints to the problem in it.

-jp

tjnemez, agreed on both counts.

Check out my site for some examples MP3 embedded within text areas. I use a thing called a Wimpy Button. Very simple to use, very attractive...
http://www.goLancaster.com

Follow this link if you decide to purchase (gets me a little kick-back, y'know?)...
http://www.wimpyplayer.com/affiliates.php?id=41

A couple of other suggestions for features...
- Back-end statistics reporting feature showing the number of reads and the number of click-throughs.
- Capability to automagically generate a weekly or monthly email to the listing customer showing them how many times their ad was viewed and how many times someone clicked through to their web site.

Bingo! We were on the same page. Sorry I didn't quite clue in on what you were writing.

My site focuses on "Lancaster County, Pennsylvania". Problem is, the county covers a large land mass that is segmented up into theoretical (fuzzy) "areas" or "regions". For instance, there are a lot of Outlet malls here and they all have a "Lancaster City" postal address. Problem is, they're actually no-where near Lancaster City itself. I guess the Lancaster City postal address conferred upon them simply makes it easier on the postal service to deliver mail. For everyone else, it can be an extremely confusing misnomer. Call any merchant in the outlets and they'd say "We're in the Strasburg Area of Lancaster County." They'd never say, "We're in Lancaster City". Other businesses in-and-around the area (restaurants, b&b's, attractions, etc.) that actually have a Strasburg postal address could associate themselves with the "Strasburg Area" region. This creates a less "legalistic" separation of content and certainly a more friendly method of grouping listings together.

Providing merchants with a way to assign themselves to an administrator defined "area" or "region" or "territory" would be a massive improvement to the xDirectory.

Just curious... do you understand what I'm suggesting with regard limiting the directory based on the "area" selected. The look-and-feel of the directory would remain the same. All the categories and sub-categories would look the same.... there would just be fewer listings.

What do you say, Martijn? Want to tackle this?

BJB, you've hit the nail on the head by sharing the BuilderB list of features. On a more microscopic level, there are some functional differences that BuilderB has implemented. Example... New data entry fields in the "submit" area; and, new-and-improved display of company information in listings area. These functional differences can be seen and experienced on his Folsom site.

Martijn, I'd be willing to contribute to the cause as well.

One area of HUGE importance to me is the ability of the site visitor to limit the scope of directory based on "fuzzy" geography. Wrap your mind around this and you'll soon understand how massively important it is to a site's visitors........

I used to live in Dallas, TX. Dallas is a geographically LARGE city. Often, residents and visitors want to find services located in a particular section or region of Dallas. Examples of regions would include "Downtown", or "Market District", or "Deep Ellum". All of these fuzzy geographic regions help to delineate Dallas neighborhoods into bite-sized chunks that a user can easily wrap their mind around.

This is a much better approach than, say, limiting the scope based on postal code.

In an ideal world, this process would be handled in a manner such as "Limit the directory to within X miles" of a specific point on a map. This method, of course, is probably very difficult to implement. However, to make the process extremely simple to implement, you provide the administrator with the ability to create a list of "regions". When a business owner adds their listing to the site, they can select which region they're closest to. Later, when a someone visits the site and they're looking for businesses, say, in-or-near "downtown", they can select it from a drop-down list of administrator defined regions and the data set that's returned to them will be limited to only those businesses that have associated themselves with that particular region.

Clear as mud?

Wow! Talk about resurrecting a thread from the dead! I think there are a lot of people out there who "feel your pain". I have a need for this module to be improved, but (like you) don't have the programming experience to make it happen.

About a year ago I talked with the guy who created xDirectory. He developed it for his site (www.folsomliving.com). He has since made many improvements to the original distribution found in XOOPS->Modules. At the time I spoke with him, however, he indicated that he was unwilling to share his improvements... basically he didn't want to give away his work to the "competition".

Regardless, this module has viability and purpose. These issues have been languishing toooo long. How can we knock this off center and get it rolling?

That's correct. When you install phpAdsNew as a module for XOOPS it will create the necessary tables directly within your XOOPS database. What it won't do is copy any existing data you already have into the newly created tables. If you have data you want to transfer, you'll need to do this manually.

Hey Snakes... just a thought here. What are the chances of securing information from noaa.gov? This is a U.S. government resource with tons of current weather info. Since the information found there is publicly funded through taxation, I wonder whether it's restricted less by copyright laws.

I can't think of many advantages. The only thing the module install seems to do is:
1) adds phpAdsNew as a selection in your administration area (basically just a link to phpAdsNew's administration area)
2) adds the appropriate tables to your XOOPS data base.

So I guess from a backup perspective, it may be convenient to have the tables all stored in the same database... but that's about the only advantage I can think of.

Hey, keep in touch if you do end up installing XOOPS and if you want to exchange ideas about how best to display ads in XOOPS using phpAdsNew.