yes Craig,
it is called "Google" ;)

---

Cheers from Germany,
Sebastian Leupold

   

Speed up your DNN Websites with TurboDNN

Thanks, both of you.

Yes, my question begged for that answer, but there was a more serious question behind it. I will explain.

I'm working with what I think is a typical situation, and one that doesn't, to my mind, have a good solution. The client has two modules that are used together to display a list of employees, each has a link to a detail page where details about a specific employee are shown. So, the first page is something like mysite.com/our-team, and that page has links to the detail page that look like mysite.com/our-team/detail/name/BobSmith. In the latter, this link is a friendly url that really is ?name=BobSmith, and the detail module uses the querystring variable to determine what is shown.

Both pages are dynamic. The our-team page is constructed from users in a specific security role. The detail page is built from the specified user's profile. So, everything is based on user profiles.

Now, the big issue is that neither the our-team nor the detail module implement Searchable (or iSearchable). {The fact that a reputable module developer built this and didn't include search is another to-be-written rant! They should be ashamed.]

But my problem is "search isn't working."

This is when it hit home that the DNN "Site Crawler" really isn't "crawling" the site and indexing the contents directly. Both Searchable and the older iSearchable provide the content to the search indexer indirectly, so this depends on two things: search must be supported at the module level, and also it must be done in a useful way. It also seems to me that there isn't a good way to handle the querystring. Further, even though the content of one module includes links that have the querystrings in them, these do not seem to be "followed" in the crawler sense.

So my options are:
Have the client go back to the original site developer and demand that the modules get fixed: not going to happen.
Fortunately I do have the source code, could dig through how it works, and add search. I think that this still fails to solve my problem, due to the querystring issue mentioned.
Find a replacement search indexer that can handle this situation - I haven't.
So I'm in search of a solution. Hence my badly formed question. But, you've got to admit it was easier to read that this version!

Oh, and with respect to #2 above, I think that the only real feasible solution is that the detail module's Searchable implementation should return "search documents" for all possible team members? That probably should work.

But, the larger question now is search. Search really don't index the contents of a site. This was somewhat of an eye opener, as I'd never really dug in the intricacies of search, and some of the design issues.

(Some years ago I used the old Xepeient search on a DNN site. I solved problems like this one because it really crawled the site. There were other issues, but I think I solved most of those!

Would it be possible (or advisable) to have a module that self-identified as "I don't support searchable, so index me directly"?

So, help and advice for you folks will be appreciated.

---

Joe Craig
Patapsco Research Group, Ellicott City, MD
DotNetNuke Development and Services (http://patapscorg.com)