內容 |
|
The bug has been fixed in the source, and the fix will be part of the next release.
|
|
|
Thanks for the heads-up. Seems to be a general bug in JForum, not just here. I'll take a look.
|
|
|
It's great that you got it going. But you really should update to Java 8 and JForum 2.7 - you're missing out on a lot of bug and security fixes, not to mention a bunch of useful features.
|
|
|
Stupid oracle - doesn't say which attribute is missing. Are you using the code from 2.3.5 with this? I advise to apply the DB changes until 2.7.0, and then run the 2.7.0 code with that. After all, you want to run 2.7.0, not 2.3.5.
I won't be able to look into things in detail for the next week or so, but I'll do then (assuming you don't get it running until then}.
|
|
|
There should be a browser menu "view source code" or "view html source" or something like that. That should contain more information.
|
|
|
The error message would appear in the log when that error occurs, not necessarily at startup.
When the error happens, is there just that little bit about SQLException, and nothing else? That would be very odd. Maybe in the HTML source code?
|
|
|
The full stack trace should say which attribute is missing. Check the catalina.out file, it contains the full stack trace. That attribute should -hopefully- be part of the 2.3.5 upgrade scripts.
|
|
|
|
|
|
It's at the bottom of each page.
|
|
|
One other thing that comes to mind is the version of JForum you're using. It looks like it is pre-2.3.5, which would make it very old indeed. Thus a lot of bug fixes are missing (not to mention security fixes), which might explain behavior like this.
|
|
|
First of all, setting the message format to HTML (or vice versa) does not take effect immediately - you have to restart the web app; did you do that? (This seems unnecessary, so I'll change that for the next release to take effect immediately.)
Edit: Actually, it should take effect immediately, but the code handling this is not thread-safe
Secondly, there is an interaction with each user's "Include the message contents within the notification email" setting. If that is set, a user will always get HTML emails, because the message contents may contain HTML.
|
|
|
Yes, that is exactly it. The problem is that it has
Content-Type: text/plain
when it should have something like
Content-Type: text/html; charset=UTF-8
I'll need to look into the code to see if there are any circumstances where the type can be set to text even though it should be HTML. I'll post here what I find.
|
|
|
Thanks, but to look into it I would really need to see verbatim copies of the complete emails - what Gmail calls "Show Original", or other email clients may call "raw". Just copying the text from out of it does not help.
I agree it's strange that different emails should behave differently - they all use the same underlying code.
|
|
|
Also, in which email client are you viewing your emails?
I just tried it with the default templates, and with the message format set to HTML, the message contains "br" tags, which GoogleMail correctly interprets as line breaks - so that looks fine to me. And if I add HTML tags to either text file, that shows up correctly as well.
So, we really need to see your templates, and the raw text of the email (not the text that gets displayed).
|
|
|
Please attach the two templates here. It would also help to have verbatim copies of the two emails (meaning, their raw text):
|
|
|