GET Forms on a Page

[cmb]

Hello Community,

I've just noticed that it's not possible to have a GET form on a page and to land on the same page after submitting it.

For POST forms the core uses $selected, which isn't necessary, as one can give the deep URL of the page in the action attribute. However, $selected doesn't work for GET requests.

We should consider to allow $selected for GET requests also. OTOH this brings up a DC issue.

Christoph

[manu]

Christoph, could you clarify, what the real problem is?

I've just noticed that it's not possible to have a GET form on a page and to land on the same page after submitting it.

How about to set $su in the action parameter?

For POST forms the core uses $selected, which isn't necessary, as one can give the deep URL of the page in the action attribute. However, $selected doesn't work for GET requests.

Please correct me, but I find only XH_contentEditor is using global $selected to relocate the page. I wonder also in this case, why $sn is used in the action parameter instead of $su. The whole admin field edit is neatly running with the url query in the action parameter.

We should consider to allow $selected for GET requests also. OTOH this brings up a DC issue.

If there isn't a important reason we should get rid of this global $selected.
But obviously I probably didn't get the problem right.
regards
manu

[cmb]

How about to set $su in the action parameter?

That is not supported by the core. $su is traditionally build from the first query parameter name, if that refers to an existing page. Otherwise $su is set from the POST parameter "selected". Since CMSimple_XH 1.6 (which addressed this thread's issue) "selected" can be passed as GET parameter, too.

For POST forms the core uses $selected, which isn't necessary, as one can give the deep URL of the page in the action attribute. However, $selected doesn't work for GET requests.

Please correct me, but I find only XH_contentEditor is using global $selected to relocate the page. I wonder also in this case, why $sn is used in the action parameter instead of $su. The whole admin field edit is neatly running with the url query in the action parameter.

Yes; that's what I wanted to say.

If there isn't a important reason we should get rid of this global $selected.

The important reason is that $selected is necessary for GET forms, because it is not possible to pass a query string from a GET form (opposed to a POST form). For instance, consider:

Code: Select all

<form action="http://example.com/?MyPage" method="GET">
    <input type="hidden" name="post_param" value="post_value">
    <input type="submit">
</form>

On form submission, http://example.com/?post_param=post_value will be requested. The query string "MyPage" is simply lost.

Since XH 1.6 the following could be used instead:

Code: Select all

<form action="http://example.com/" method="GET">
    <input type="hidden" name="selected" value="MyPage">
    <input type="hidden" name="post_param" value="post_value">
    <input type="submit">
</form>

Before CMSimple_XH 1.6 the solution was to use POST forms instead of GET forms, even when POST was not the appropriate method (e.g. for search forms). See also http://cmsimpleforum.com/viewtopic.php?f=29&t=8261.

However, in the meantime I noticed another related problem wrt. to GET forms in the plugin administration. I'm not sure, if I started a respective thread -- I'll have to investigate. Anyhow, the problem is how to pass the plugin name from a GET form. Currently that is not possible, so you can't use GET forms in the plugin administration. That's a rather annoying limitation when, for instance, filtering or pagination are needed/desired, and has to be worked around by using POST forms and/or Ajax requests. The problem could be easily solved by expecting the pluginname as the value instead of the name of a GET parameter (what would mostly solve the unreliable setting of $s issue), but that would be incompatible with existing plugins resp. older CMSimple(_XH) versions.

[manu]

How about to open the functionalitiy of $selected to PLUGIN_NAMES ("?selected="myPLUGIN") as the plugin is a page as well - at least in admin mode? Honestly I don't remember the last time I had the need for a GET Form, do you?
regards
manu

[cmb]

How about to open the functionalitiy of $selected to PLUGIN_NAMES ("?selected="myPLUGIN") as the plugin is a page as well - at least in admin mode?

That is an option, but I would prefer to get rid of the plugins to occupy the namespace of toplevel pages. Some plugins have rather common names, for instance, Calendar, so currently it is not possible to have a toplevel page"calendar". Not a big problem, as the page name would probably "Calendar", but what about a user who uses urichar_org/new to enforce lower case query parameters for the page names? That leads to rather strange results when he's logged in as admin.

Also we have to consider that it is possible to request ?myPLUGIN as well as ?&myPLUGIN (and both variants are in widespread use). Actually the position of the plugin name parameter does not even matter, so one could request ?myPLUGIN&anotherPLUGIN. Pretty strange, IMO.

Honestly I don't remember the last time I had the need for a GET Form, do you?

I had the need for Register_XH, which has a filter form for the state of the blog articles. I had to leave it as a POST form, whereas a GET form could be quite useful for an advanced user who could bookmark the respective URL.

For some other plugins I have a list of items in the back-end, where a user can choose to edit or delete the item. For simplicity I'm doing the delete directly as a POST form, but I can't easily use an edit button, because a GET form won't work. A link is functional, but it looks strange. A click button with an onclick event handler (window.location = "...") also works, but I don't actually like it and it is not really accessible.

PS:

However, in the meantime I noticed another related problem wrt. to GET forms in the plugin administration. I'm not sure, if I started a respective thread -- I'll have to investigate.

Ah, that's already on the roadmap for XH 1.6.5: Submit GET form to the plugin adminstration.