Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Liferay 7: Liferay language selector portlet fails when in review mode #3978

Closed
ebruchez opened this issue Mar 8, 2019 · 6 comments

Comments

Projects
1 participant
@ebruchez
Copy link
Collaborator

commented Mar 8, 2019

I do reproduce this:

  • navigate to review page
  • use the Liferay language selector portlet to change the language
  • error shows

+1 from customer (also here)

@ebruchez

This comment has been minimized.

Copy link
Collaborator Author

commented Mar 21, 2019

So what should happen in this case? I have French as default language now.

Say the form's edit page shows:

http://localhost:8080/fr/web/guest/form-runner?
p_p_id=orbeonformsproxyportlet_WAR_proxyportlet_INSTANCE_Hwv0RbB7M43X
p_p_lifecycle=0
p_p_state=normal
p_p_mode=view
_orbeonformsproxyportlet_WAR_proxyportlet_INSTANCE_Hwv0RbB7M43X_orbeon.path=%2Ffr%2Forbeon%2Fbookshelf%2Fedit%2Fc634d988df9afe97ac0b805b6c8196b64ef68bdf

When the language selector is clicked to "English", that portlet loads a side-effecting path to change the language:

http://localhost:8080/fr/c/portal/update_language?
p_l_id=30228
redirect=%2Ffr%2Fweb%2Fguest%2Fform-runner%3Fp_p_id%3Dorbeonformsproxyportlet_WAR_proxyportlet_INSTANCE_Hwv0RbB7M43X%26p_p_lifecycle%3D0%26p_p_state%3Dnormal%26p_p_mode%3Dview%26_orbeonformsproxyportlet_WAR_proxyportlet_INSTANCE_Hwv0RbB7M43X_orbeon.path%3D%252Ffr%252Forbeon%252Fbookshelf%252Fedit%252Fc634d988df9afe97ac0b805b6c8196b64ef68bdf
languageId=en_US

The response to that is a 302 redirection to:

http://localhost:8080/web/guest/form-runner?
p_p_id=orbeonformsproxyportlet_WAR_proxyportlet_INSTANCE_Hwv0RbB7M43X
p_p_lifecycle=0
p_p_state=normal
p_p_mode=view
_orbeonformsproxyportlet_WAR_proxyportlet_INSTANCE_Hwv0RbB7M43X_orbeon.path=%2Ffr%2Forbeon%2Fbookshelf%2Fedit%2Fc634d988df9afe97ac0b805b6c8196b64ef68bdf

This is almost the same path as the starting path, except that there is no /fr prefix. Here /fr means "French", not "Form Runner" ;) If I switch to German, the resulting URL starts with /de.

During that first language change, the edit page was obtained via GET. If I make a change in the form data without saving, the attempted navigation will cause the "Changes you made may not be saved" alert to show up. So this is not that great either, but the user has a chance to address this and refuse the language change.

Now, when I do a "Review", an action URL happens, which is double-pass submission happens and an HTTP POST happens. Changing the language after that follows the same process as above, and a GET is issued for that URL.

Now, the proxy portlet is supposed to cache results coming from actions. So we need to see if this behavior is a bug of that mechanism, or due to something else.

@ebruchez

This comment has been minimized.

Copy link
Collaborator Author

commented Mar 21, 2019

Logic of actions in our portlet:

  • Upon a view action, we store in the portlet session a ResponseWithParameters object.
  • Upon a render from the portlet, we check that stored response. We use it if and only if its parameters match.

with:

case class ResponseWithParameters(
    response   : BufferedContentOrRedirect, 
    parameters : Map[String, List[String]]
  )

This suggests that, possibly, we don't have the same parameters and the comparison of parameters fails?

@ebruchez

This comment has been minimized.

Copy link
Collaborator Author

commented Mar 21, 2019

  • check parameters set/changed by the Form Runner action and compare them with the parameters of the failed GET
@ebruchez

This comment has been minimized.

Copy link
Collaborator Author

commented Mar 21, 2019

The POST has:

http://localhost:8080/fr/web/guest/form-runner?p_p_id=orbeonformsproxyportlet_WAR_proxyportlet_INSTANCE_Hwv0RbB7M43X
p_p_lifecycle=1
p_p_state=normal
p_p_mode=view
_orbeonformsproxyportlet_WAR_proxyportlet_INSTANCE_Hwv0RbB7M43X_orbeon.path=%2Fxforms-server-submit
p_auth=TvopHXKD

And the GET:

http://localhost:8080/web/guest/form-runner?p_p_id=orbeonformsproxyportlet_WAR_proxyportlet_INSTANCE_Hwv0RbB7M43X
p_p_lifecycle=1
p_p_state=normal
p_p_mode=view
_orbeonformsproxyportlet_WAR_proxyportlet_INSTANCE_Hwv0RbB7M43X_orbeon.path=%2Fxforms-server-submit
p_auth=TvopHXKD

The parameters (orbeon.path=%2Fxforms-server-submit) appear to match.

Form Runner receives a GET /xforms-server-submit, which is not found, of course.

This said, even if action caching worked in the portlet, the Form Runner language wouldn't change at that time. But that would certainly be better than crashing.

@ebruchez

This comment has been minimized.

Copy link
Collaborator Author

commented Mar 21, 2019

Ah, noting that upon an action, we store orbeon.method=post as parameter. So this would explain why the comparison fails.

In general the method makes a difference, but it sounds like we should handle the special case of /xforms-server-submit specifically: a POST to that should support matching a GET.

@ebruchez ebruchez added this to To review in Orbeon Forms 2019.1 via automation Mar 21, 2019

@ebruchez

This comment has been minimized.

Copy link
Collaborator Author

commented Mar 22, 2019

It turns out that there is more. When we change the language on the view page, we get a replay of the action. The reason is that the Liferay language selector portlet is, essentially, broken: it just applies the current URL but with a GET. So we get, at the portlet level, an action but with a GET.

@ebruchez ebruchez closed this in 8562b71 Mar 25, 2019

ebruchez added a commit that referenced this issue Mar 25, 2019

Orbeon Forms 2019.1 automation moved this from To review to Done Mar 25, 2019

@ebruchez ebruchez added this to To do in Orbeon Forms 2018.2.3 via automation Mar 25, 2019

@ebruchez ebruchez moved this from To do to Done in Orbeon Forms 2018.2.3 Mar 25, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.