<base> tag in Plone 4 edit forms (Archetypes and Dexterity)

1

Plone 5 uses a post-traversal hook to remove <base> tag injected by ZPublisher.

What risks are involved with doing something similar in a Plone 4 integration?

While there are other more targeted solutions like PRs [1, 2] by @rodfersou for plone.app.layout default pages in Plone 4, this is carefully targeted at just default pages.

My current use case is to fix for edit forms in Archetypes and Dexterity (because <base> does not play nice with mockup Autotoc pattern for form tabs, and I'm working on plone.app.widgets 1.x improvements).

Thoughts about a blanket rip-the-tag-out approach? What does this break (besides folder_rename_form)?

While I think this may be too risky to commit into plone.app.widgets 1.x branch, I think I (and likely others) want to use a post-traversal hook like this in policy product usage.

Sean

2

There are some Javascript code that looks into tag href attribute to take the context url, and it would break, this is one case where it happens.

3

I just grepped my omelette, and realized too much Plone 4 JS needs base to exist in DOM (not necessarily in source):

omelette sean$ grep -r '$(.base.)' *

It may be possible to rewrite base href client-side to avoid breaking this JS, but it needs to be injected before other scripts run (likely by viewlet):

(function () {
  "use strict";

  var head = document.getElementsByTagName('head')[0],
      existing = head.getElementsByTagName('base'),
      base = document.createElement('base');
  if (existing.length) {
    head.removeChild(existing[0]);
  }
  base.setAttribute('href', window.location.href);
  if (head.firstChild) {
    head.insertBefore(base, head.firstChild)
  } else {
    head.appendChild(base);
  }
}());

Getting order right in the Plone 4 JS registry is a pain, and not robust when you are installing a large dependency chain of multiple add-ons, so I think this needs to be in a viewlet guaranteeing it is evaluated first, before all other scripts (cannot assume jQuery, so transform above is all just DOM API) are loaded.

Doing (just) this client-side transform may avoid need for post-traversal hook to remove server side.

Thoughts? How robust would using window.location.href in all cases for base be? Would inclusion of querystring (e.g. authenticator token) in window.location.href break anything in the various JS code in Plone 4?

Sean

4

Ok folks, I have a proposal for those interested in fixing this situation for Plone 4:

(1) Will someone comfortable with plone.app.layout review and merge the two PRs @rodfersou has submitted (see links above). These don't solve all the cases where <base> can cause trouble, but they do address a common problem with default pages.

(2) For folks interested in doing anything more in Plone 4 than the limited case above (like me interested in fixing <base> in AT/DX edit forms for plone.app.widgets integration, using the JavaScript rewrite I posted above in your integration (policy product) in a viewlet seems a reasonable solution that likely won't break any OOTB or add-on JavaScript (YMMV).

Sean