Adjusting exp:channel:form's return= parameter via javascript?

The return parameter is server-side, and isn’t related to the form’s action, which would be processed properly regardless of the endpoint so long as it reaches ExpressionEngine. And after a valid submission, the server-side stored location set by the site builder is used to redirect the user to the proper location.

In general, there isn’t any way to influence an ExpressionEngine tag’s parameters (or PHP) with JavaScript—they are server-side, and JavaScript is client-side. The only mechanisms available for that require passing information from client to server and back. For instance, you could set a cookie or URL segment with JavaScript on clicking the link to go to the form that you would then read on subsequent requests from ExpressionEngine to use in its tags. Make sense?

OK - thanks Derek.

I take your comments to imply that it doesn’t matter at all what value of ‘return’ is set in the form that is created by channel:form when it renders on the page - control will be passed to the value set in the server side parameters regardless. This seems odd: if this is true it is not clear why channel:form creates all the normal form related fields (including return) during its rendering. But happy to go with the flow etc.

The issue is a strange one. I’m helping to update an old (EE2.5) site created by unknown parties long ago). The old site used jquery to attach ‘on-click’ events to the various buttons used to submit a channel:form. The on-click function was to replace the form’s input ‘return=’ with a url dependant upon which button pressed, and then validate and submit the form. This method seemingly worked to provide different function / destinations for the channel:form in the past but works no longer (EE 2.11.9).

I guess I’ll fix some other way, but sort-of curious to know what changed that means it doesn’t work in 2.11.9.

Do you mean the action= attribute? There isn’t a return= attribute for an HTML form tag. Can you clarify what you’re referring to?

This method seemingly worked to provide different function / destinations for the channel:form in the past but works no longer (EE 2.11.9).

Yes, that sounds right. Ages ago there was a security fix to the original code (Safecracker at the time) that prevented client-side tampering of many of Channel Form’s parameters. A visitor should not be able to manipulate ExpressionEngine functionality by modifying the DOM before submitting a form. Imagine them being able to set statuses, for example.

Can you describe the specific behavioral needs of the flow? How are these forms being used that JS is needed to change how they function on click?

To be blunt I’d not ever seen this type of thing before. However it is also true that a hidden input field (name=”return”) is generated with the URL of the return page and included in the form on rendering - it is happening on our test site and is (for example) illustrate in this post in this forum from 2012 - https://expressionengine.com/forums/archive/topic/222466/passing-channel-entry-field-content-to-contact-form - so I imagine that the pre-flood scheme somehow worked by messing with that value.

As for whether it is a good or bad idea - I’m with you on bad, but it would be an odd website that could be compromised via such methods: presumably the member model in EE (for example) would prevent scurrilous use of such things.

Anyhow - for completness, the buttons are “save and stay on page”, “save and make new” and “save and make new with this data”. Current plan is to replace with filtering / routing on a common destination page and then generation of the appropriate end point based on variable set by button.

Gotcha. There is currently an undocumented entry_submission_redirect hook that could handle that server-side.