Will need a little more time to test direct access, but will definitely do so.
For comparison, is anyone using the ShortViewURLConstructor and seeing user
preferences work for pages under its prefix?
Thanks,
--
Jim Wise (he/him)
jw
Hi!
Is it possible that the Apache config, as it is, works for the default url
constructor, but it's not enough for the short url constructor?
Or the same question, from other point of view: if you access to your
JSPWiki instance directly through your tomcat installation instead of
through the Ap
Found the problem, sort of.
We’ve been using jspwiki.urlConstructor = ShortViewURLConstructor, with a
prefix of /wiki. If I switch to DefaultURLConstructor, everything works fine —
and I no longer have separate “/“ and “/wiki” versions of the JSPWikiUserPrefs
cookie.
This may still well be ap
Hi Jim,
Would you mind trying accessing directly to your tomcat's instance and see
if everything works as expected?
It seems to me that the problem is probably sitting at the Apache
configuration (the cookie handling); digging through the MLs' archives I
found [#1], which depicts a similar situat
Hi!
To add to this, I see no errors in the javascript console throughout, with one
exception, which is odd, but I believe not relevant:
Parsing application manifest
https://wiki.draga.com/wiki/favicons/site.webmanifest: The manifest is not
valid JSON data.
Looking at that loaded resource, it
Interestingly, the edit page itself also obeys user preferences. It is only
Wiki content that is not getting it.
--
Jim Wise (he/him)
jw...@draga.com
> On Aug 17, 2023, at 12:37, Jim Wise wrote:
>
> For completeness, I have
For completeness, I have also tried with ProxyPass/ProxyPassReverse using HTTP
instead of AJP, with no change.
--
Jim Wise (he/him)
jw...@draga.com
> On Aug 17, 2023, at 11:55, Jim Wise wrote:
>
> Thank you — there is an apac
Thank you — there is an apache reverse proxy in front of tomcat, communicating
with tomcat via AJP.
I have ProxyPass and ProxyPassReverse set, but do not have
ProxyPassReverseCookiePath set, as the path is the same in front of and behind
the proxy (I’m mapping / on the apache virtual host to /
Hi Jim,
Do you have something in front of your tomcat instance (an Apache web
server or something like that)? In that case, f.ex., for Apache you have to
set some directives: proxypass, proxypassreverse and
proxypassreversecookiepath, IIRC.
Another thing to check would be your JSPWiki user prefs
Hi Jim,
I have tested this on the official JSPWiki page and can confirm that
everything works as expected. After switching to dark mode and saving the
preferences, I was redirected to the main page with the dark theme applied.
The same goes for the Section editing; it works as intended. Have you t
As an update, some playing with this seems to show that this is an issue with
user preferences in the wiki here, not just with section editing.
As a concrete example, if I turn on dark mode in the preferences, this changes
the appearance of the preferences screen, and of the login screen, but
d
Hi!
Editing itself works great. Section editing links no longer appear next to
each section heading, however, so I can only edit the whole page.
I’ve just logged out, cleared all data (Cookies, Cache, and Local Data) from
our wiki, then logged in and turned section editing back on in my user
Hi Jim,
I've just tried section editing at jspwiki-wiki.a.o (currently running
2.12.1) and it seem to work well :-?
Would you mind trying to refresh the browser's cache and see if that does
the trick?
I don't recall any change for section editing (or js changes, generally
speaking) between 2.11.
Hi!
Before I dig deeper, is section editing working for anyone under 2.12.x?
Just got a report that it had been broken “for quite a while”, and turning it
on verifies that its is indeed not working under 2.12.1 on OpenJDK 11.0.20 and
Tomcat 9.0.79.
I’m sorry not to have further clarity on “for
14 matches
Mail list logo
