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?
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.
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.
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 plone.app.layout #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 plone.app.widgets 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.
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?
@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 basehref. 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 basehref 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.