Thread

You’ll have to refresh your page the first time before things will pick up working with this new setting.

I made the change and tested it in a new browser window and still got the same three errors.  I then tried the uninstall/reinstall of the Search and the cache clear and the errors are still there. 

The menus/links are still working, though.

Ok, I didn’t want to explain my thinking on that one, but it relates to what I’ll ask next, and last for the evening.

Go to your system/expressionengine/config folder, and edit config.php. Take a copy first for safety.

Look around line 80 for a clearly labelled section called, in comment, URI PROTOCOL. It will offer some alternative settings for the assignment below the comment, which probably looks like:

$config['uri_protocol']    = "AUTO";

Please replace the assignment value “AUTO” with “QUERY_STRING”, being careful not to disturb quoting and other syntax.

Now try your site again, and see if that does it. If this doesn’t work, then try the alternate setting to “REQUEST_URI”, since you have that filled in from PHP data.

What we are doing is tuning more specifically how EE gains that query string argument. I’m not at all sure why it would pick up the menu-routing path information properly, which is the usual problem, and not a standard query string, but let’s see what happens.

If this doesn’t work, we should both let it go for the evening, and see what the support crew will suggest overnight or in the morning. I’ve been off looking for the troubles people usually have with Windows servers, but not finding anything beyond path issues - not query strings themselves, as is failing in a rather obvious way for you in this search issue. That should help it get found, and we’ve covered a lot of ground towards that tonight.

Regards,
Clive

So…

REQUEST_URI broke the whole site.  The stylesheets stopped working and every page rendered the homepage.

QUERY_STRING only broke the navigation - whatever I clicked went to the homepage as though it was ignoring everything after the .php in the URL.

Thank you again, Clive, for all your help tonight.  Hopefully we’ll get some good news tomorrow!

Well, it’s a tricky area—that’s why it’s in the so-called ‘hidden’ configuration. There’s probably interaction with that forced query strings option also—combinations that will and won’t work.

I presume neither of these options let the search itself work?

xiik, I think we’ve done good work this evening. Let’s see what the men and women who live and breath the code will suggest, based on the information, or something we’re forgetting, if there is 😉.

Regards,
Clive

xiik, if you’re on a Windows box, you need to force query strings, so that you use index.php? instead of index.php in your URLs.

How are you creating your links?

Sue, to recap here, as you can read above, we had him force query strings - it didn’t help the underlying problem; hence the concluding experiments with the config usually used to recover path information.

However, his URL paths work, with or without forced query. You can try his site link above and see.

What doesn’t work are form submit field values - the form used for the search, where he is getting errors.

Specifically the missing meta argument is causing his main error in search - the second line 370 one.

I just realized in writing this down that there might be a further strangeness which may throw a light on what is actually going on. It is that the URL line showing in the browser return when you run his search is an ACT= line, showing as a GET.

But that ACT= and its arguments come from the search form—thus should be invisible, as it’s sent and retrieved as a POST, not a GET. And the browser line showing _should_ be a redirect-caused simple GET for the results page.

Not quite sure how that can happen, especially vis a vis Microsoft IIS, and I am going to let you and the developers read the code to see, as I’m out of time for this one here. But interested.

It clearly isn’t related to the actual search issues we solved above; and pretty surely is something with the Windows server arrangement, as you’re headed towards.

Thus you may want to split this part off into its own thread—even after the fact of what looks below like there’s been a resolution to a Windows IIS server problem.

Regards,
Clive

xiik, looks like you got it working. I think we’d all be curious what you or your hosting partner did.

After some research on Windows IIS Server issues, I found that indeed there are one or more security permissioning systems, such as URLScan, which can cause POST not to operate, if not configured to allow it.

Assuming this might be verifiable, I went to your site this following-day afternoon and ran the contact form. It appeared to work, though not conclusively. Thus I went to your media page where we started, and tried the search.

Today search worked properly. Was it a permissions problem on the hosted server, or something else they informed you about?

By the way, that is also quite fast-response hosting, at least as shows consistently from San Diego. Looks like XO Communications Cloud - is that correct?

Thanks,
Clive

Hi guys, sorry for the delay.

I originally was going to say that we probably should focus on the simplest thing, but I didn’t.

Our designer who cut up the site had put form tags in that I didn’t see, so there was another form around the search form.  Took that away and everything worked fine.

Sorry for the mistake, guys.  Four hours of my life I’ll never get back.  Sorry for wasting your time.  Thank you so much for your help!

Well, that’s a good one…I suppose interactions-a’plenty caused the odd clues.

Glad you’re on the air, xiik.

Regards,
Clive

Again, my suggestion is to cut xiik’s page of additions to its own thread, and close that.

It hasn’t anything to do with the actual search bugs or fixes needing their attention here.

Regards,
Clive

Tell ya what, I’m going to go ahead a close this thread.. and if anyone needs to open another one, please feel free to do so.