This is only done to improve worst-case latency, because
we perform one additional request per result.
Local testing showed a latency above 1000ms for 50 results
and ~500ms for 20 results. I'd expect real world scenarios to
be slightly worse, because of higher network latency.
Instead of raising an error, we use throw-catch based control flow
to return the same failure that would be returned if the response
had not been JSON at all.
We now have two ways to fetch page infos from XWiki:
* using the canonical identifier (but through a new endpoint that will resolve stable identifiers as well)
* using the stable identifier
Since we want to store the stable identifier, the stable version is the one exposed through the XWiki registry.
The canonical form is required to fully resolve some list queries from XWiki properly.
This represents XWikis default way of representing page references, but
those are susceptible to become invalid after a page or space gets renamed.
We'll also support other page references, so it's important to distinguish that
multiple reference types exist.
Making them consistent with the internal wiki view.
Essentially we have a two-level navigation on the left
and that needs to be reflected in the breadscrumbs everywhere.
Fix vertical content jumps in the BlockNote editor on selection
BlockNote 0.51 puts the className we pass to <BlockNoteView>
(`block-note-editor-container`) onto BOTH the outer `.bn-container`
wrapper AND an inner wrapper that does NOT carry `.bn-container`. With
the previous selector matching by class name alone, every rule cascaded
onto both nesting levels — most importantly `display: flex`,
`flex-direction: column-reverse` and `gap: 10px`.
Two flex layouts stacked one inside the other meant that whenever the
side menu / drag handle plugin views re-rendered (which happens every
time the selection moves or the mouse leaves the editor), both layout
calcs ran and the inner wrapper's gap shifted the visible content by a
few pixels.
Tightening the selector to `.block-note-editor-container.bn-container`
restricts the rules to the outer wrapper only; the inner wrapper falls
back to defaults (`display: block`, no gap) and stops contributing to
the layout.
Refs https://community.openproject.org/wp/STC-779
Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
Feedback from devs that were confronted with the "is not an allowed host"
message shows, that the message is not very actionable. It's not clear why something
that is clearly a legitimate and existing host would be considered "not allowed".
The new error message clearly points at the SSRF policy as the source. Making the
problem more search engine friendly and hopefully allowing admins to better understand
what they have to fix.
Use stable scalar keys for Angular `@for` loops with rebuilt object
values across breadcrumbs and related list templates to avoid DOM
recreation warnings.
https://community.openproject.org/wp/DREAM-707
ulferts