Problem/Motivation

To recreate this problem, install panels 3.3 and the latest dev release of Secure Pages. Enable the node template panel, add a variant for a content type, add a field from that entity, and try to edit the style. It will fail with:

An AJAX HTTP request terminated abnormally.
Debugging information follows.
Path: http://foo.bar.com/ttps%3A//foo.bar.com/panels/ajax/editor/style-settings/panel_context%253Anode_view%253Anode_view_panel_context_3/region/center
StatusText: 
ResponseText: 
ReadyState: 4

Basically any form action that is set to an absolute URL in the panels code will cause this response.

There are six places in the Panels code where an absolute URL is used for the form action. There are plenty more where a relative URL is used. Is there a reason to use an absolute URL in some places? For example, if the Panels code is changed to use relative URL on the styles setting form, then the URL is not malformed and Panels appears to work properly.

Granted this behavior is due to interplay with Secure Pages module (and there is a bug in its url altering code that is triggered because of the absolute URL), my question is whether there is a design reason to use an absolute URL in Panels. The absolute URL is not ubiquitous in the Panels code and does not seem to be needed based on my observations.

Proposed resolution

Remove the code creating an absolute URL. See the patch.

Remaining tasks

Review, test.

User interface changes

None.

API changes

None.

See #1668324: An AJAX HTTP error occurred. PHP 5.4 .

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

solotandem’s picture

Status: Active » Needs review
FileSize
1.91 KB

Patch only changes the three occurrences of absolute URLs in the file: plugins/display_renderers/panels_renderer_editor.class.php.

If you agree with the change, then the other two files should be added to the patch:
plugins/layouts/flexible/flexible.inc
plugins/page_wizards/landing_page.inc

I have not tested them, however.

merlinofchaos’s picture

Do the relative URLs work properly if your site is installed not at the top level? i.e, http://www.example.com/mysite -- that's why I was using absolute URLs.

solotandem’s picture

I have not tested it in that configuration.

If the non-top level use case is the reason for absolute, then why would you not need the absolute URLs on other forms? In the styles wizard forms, the absolute URL is used on the second step..style settings, not the first..style type.

BR0kEN’s picture

I've a little bit corrected the patch and approved it necessity.

The Securepages module has the following code in the securepages_form_alter() function:

$url = substr(rawurldecode($form['#action']), strlen(base_path()));

The base_path() function will return the / or path to Drupal installation. The problem starts when $form['#action'] contains absolute URL and the substr function trim directory path from it.

For example:

The next URL:
https://example.com/panels/ajax/ipe/style-settings/panelizer%3Anode%3A20036%3Apage_manager/pane/ID/
will be transformed to:
ttps://example.com/panels/ajax/ipe/style-settings/panelizer%3Anode%3A20036%3Apage_manager/pane/ID/
and form submission will occur an error.

Status: Needs review » Needs work

The last submitted patch, 4: panels-replace-absolute-urls-2029839-4.patch, failed testing.

BR0kEN’s picture

FileSize
1.55 KB

I'm really sorry for previous uploaded patch, that was a mistake.

BR0kEN’s picture

Status: Needs work » Needs review
solotandem’s picture

The patch you submitted is identical to the one I submitted two years ago. Was this intended or am I missing something?

BR0kEN’s picture

Yep, sorry, I've made a mistake.

But I hope that maintainer pay attention to this issue.

dwkitchen’s picture

Status: Needs review » Needs work

As said in the first comment the patch needs to be extended to cover:
plugins/layouts/flexible/flexible.inc
plugins/page_wizards/landing_page.inc