How to get context url in JS on Plone >= 4.3.12

The base tag href attribute value no longer (since 4.3.12) points to the context object when in e.g. an edit view. Sadly this breaks JS code that relied on the old behavior.

How should the context object url be fetched in JS now?

UPDATE: Found an old discussion on this.

Apparently this change also broke Plone inline validation (since fixed using a case-specific solution that cannot be used as a global fix).

Basically you use location.href instead of <base> tag.

Take a look here for more elaborated example.

Thanks, I already saw that. But as far as I can tell, that only works for known cases, ie. you e.g. know that the URL always ends in "/edit" or "/view" so you know to strip those away to get the context.

It's not a replacement to what the base href used to provide.

It seems to me we should extend plone_javascript_variables.js to provide the context URL, should we not?

This can work.. or maybe add a data-context-url attribute at <body> tag.

True, but that requires an extra parsing step, and given that plone_javascript_variables has other variables, too..? Are there some benefits?

From what I understand of the base tag and how Plone works, it seems to me this change makes Plone diverge from the purpose of the tag and breaks what people would naturally expect the base href to contain. Or maybe it's just my personal expectation and perhaps there's something I don't understand that makes the new behavior equally valid - I would be grateful to have that explained to me.

In any case, I'm not going to start advocating rolling the whole thing back, but I do fear that we're going to see some more broken add-ons and issues. Providing an alternative means at getting at the context from JS would be a goodness.

Well.. there was a really old issue showing problems provided by the use of <base> tag, and I was bitten by this bug after a long time and fixed it

I don't know where the original text of this issue is now, if it can be restored someway.. and don't remember details about this bug.

AFAIK that was a bug; a bug so old that probably people get used to work around it, but a bug in any case.

according to Mozilla's documentation, you should be able to get the same using document.baseURI.

I am not sure I understand what you mean @hvelarde - document.baseURI is just a script convenience to provide access to what's set in the base tag's href attribute. It does not provide access to the context.

@hvelarde I guess you mean the 12-old imported bug you refer to in the #86 referred to by @rodfersou above. I wish the original bug was available but it seems it's no longer online.

But, apparently the actual beef of the said issue #86 was:

"folderish item with default page defined: base tag and URL must be the same (this is the actual issue here)"

Correct? What I do not understand is: why should that mean that the base href has to always be the same as the actual URL, also in views? As is now the case, after the change in 4.3.12.

In other words, before, the base href in say, editing view of any content ( /edit) was the URL of the context, ie. without the trailing /edit. Made sense. Now, it's the URL of the view including the /edit. The reason for issue #86 (quote above) said nothing of changing this or it the old behavior being a problem.

I am starting to wonder whether this is an undesired side-effect of #86 that we should file an issue for?

I can see the question of edit views I raised above has been discussed later down in #86, but the discussion there gives no other reason why the old behavior was undesired except that (quoting): "it breaks correct URL for page refresh when one is using the autotoc pattern from 1.x for form tabbing".

Apparently PLIP #13705 removed the base tag injection in Plone 5. Could somone point me to the PLIP text or review? I could not find the PLIP text or background or anything in CMFPlone issue tracker explaining why the base tag was removed. Neither could I find anything in svn where some old PLIP reviews were.

Oh my. Looks like plone_javascript_variables.js is long gone from Plone 5, so we should not make the context URL available there as a variable. The changelog says it's gone because "necessary values are provided on body tag and pattern options".

@rodfersou, it looks like your suggestion of adding a data url is future-proof: Plone 5 sets a data-base-url body tag attribute to the url of the context. :+1:

I would be happy with just that (made available in Plone 4.x). But while at it, I wonder if we should backport some more data-* settings from Plone 5? Anything that would be useful?


yes, it's a pity that we lost the original tracker because it had a lot of relevant information.

whatever makes the migration path easier is very welcomed, IMO.

@petri just to be clear, is there any issue pending on this? are you still having problems?

AFAIK @mauritsvanrees solved the issue with validation after the release of Plone 4.3.12, but as we lack the complete background on the problem I don't know if we need to fix anything else.

I don't know of any (additional) issues in Plone 4 core caused by the changed base href. I don't know of any issues in commonly used add-ons, either.

Given the change is fairly recent, I suspect some may still lurk out there though.

I would suggest we do what Plone 5 already does: add a data-base-url attribute to the body tag, and if any issues still arise because of base href change, recommend using the new attribute instead. That would provide a nice path forward.

Perhaps this is as simple as a minor addition to main_template and a sufficiently descriptive changelog entry?

I did that to fix some code that would otherwise have broken a customer site when upgraded to newest Plone 4.3.x.


I created issue #2051 for this.