perform search requests with nice url

[Timbalu]

Is there an easy way to force search form GET submits to immediately link to /search/foo ?
I would like to get rid of /index.php?serendipity[action]=search&serendipity[searchTerm]=foo*&serendipity[searchButton]=Go!

[kleinerChemiker]

No, because this is done by your browser.

[garvinhicking]

Hi!

Well, it could be done with javascript catching the "onsubmit" event, and then targetting a URL via location.href. But this is IMHO a bit whacky... and would rely on a non-JS fallback, so that wouldn't be so terribly beautiful to code.

Regards,
Garvin

[Timbalu]

Yes, true... what about htaccess?

[kleinerChemiker]

htaccess is server side, but the url is created by your browser.

[Don Chambers]

On [url = http://board.s9y.org/viewtopic.php?f=11 ... 5&start=67]this page[/url] I mention something similar... I want to be able to detect "functional" pages in the admin backend... such as "manage styles". However, the url changes based on the action performed, such as selecting a new template, or changing template options. Is there a way to always emit the same url regardless of the action taken?

[garvinhicking]

Timbalu: Of course you could use .htaccess and mod_rewrite, but then you'd hit the server twice with the requests - IMO this is not beneficial.

Don: I'm not really sure what you mean? The order of GET parameters could change, but those shouldn't matter...?!

Regards,
Garvin

[Don Chambers]

Don: I'm not really sure what you mean? The order of GET parameters could change, but those shouldn't matter...?!

The GET parameters are part of the url. Those parameters change making it very difficult to do a conditional test to a very specific string. I'm trying to find a way around that. I ran into this once before doing a form... a GET added the parameters to the url, while a POST did not. Both worked fine.

[Timbalu]

Timbalu: Of course you could use .htaccess and mod_rewrite, but then you'd hit the server twice with the requests - IMO this is not beneficial.

Yes, that is true, but it should be faster than the same procedure involving Serendipity twice, while sending the form with method="post" and have this in templates config... e.g.

Code: Select all

if ($serendipity['POST']['action'] == 'search' && $serendipity['POST']['searchTerm'] != '' && $serendipity['POST']['searchButton'] != '') { 
    $q = $serendipity['POST']['searchTerm'];
    header( 'Location: ' . $serendipity['serendipityHTTPPath'] . 'search/'. $q);
}

[garvinhicking]

Hi Don!

Sorry, can you describe i.e. with examples what you try to do?

Timbalu: The best way is to not rewrite URLs like these that involve POST requests. What you write is not really good, it would eat up performance that would be noticeable. The whole s9y API, the dataase connection, the template layer - all would have to be loaded just for this simple redirect, and the only benefit would be a nice URL...

Regards,
Garvin

[Timbalu]

Yes I know, that is what I was trying to say...
But sending this search form via post only, without forcing it to GET again, isn't working.
So IMO there are only 3 solutions. Rework the cores request API to also allow POST request there (did not have a look why), do a workaround via htaccess or waive to have nice urls here.

[kleinerChemiker]

I don't have the code of the api here, but this change shouldnt be too dificult. It's just a swith from $_GET to $_REQUEST.

[garvinhicking]

Hi!

I understood it like that: You want to have a way that the search goes straight to http://yourblog/search/searchword - right? This is *NOT* possible, it would mean to append the input of a form field to be appended to the URL. This can ONLY be done via Javascript.

What *could* be done is make the search go to http://yourblog/search/ and submit searchword as a POST form. Since s9y relies on $serendipity['GET'] and $serendipity['POST'] we have no real $serendipity['REQUEST'] equivalent. But in the genpage.inc.php we could easily set

Code: Select all

if (empty($serendipity['GET']['searchTerm']) && !empty($serendipity['POST']['searchTerm'])) {
    $serendipity['GET']['searchTerm'] = $serendipity['POST']['searchTerm'];
}

This could be added to include/compat.inc.php, right before we apply striptags to $serendipity['GET']['searchTerm']...

Then, the templatre itself could decide on whether to use a GET or POST request...

Regards,
Garvin

[Timbalu]

Yeah, that would simply be the very best to work with POST search requests either.
But it would loose the benefit of direct addressbar-information that a request has been send (and I love the short one! ).
Shall we include that POST possibility anyhow? I'm ok if not.