Message |
|
That doesn't look like the right fix, but don't worry - I already have a fix, and just need to test it. Patience 
|
 |
|
Yes, that's exactly what it is.
|
 |
|
What I meant is: if at least one of them has HTML turned on, and at least one of them has it turned off.
Yes, that code section may well be the problem.
Config info is taken from the SystemGlobals.properties and jforum-custom.conf files. The DB table serves mainly as a backup of jforum-custom.conf.
|
 |
|
I think this can happen if some of the users have "Allow HTML" turned on in their profile, and some users do not.
|
 |
|
I'm not sure, as I don't use HTML emails, but I'll take a look.
|
 |
|
In the file templates/default/user_profile.htm, replace registrationDay with registrationDate - that will use the format you selected. Note that in the topic view, the format will still use the short version "Jul 6, 2011", because there space is at a premium.
Attached is a new JForum jar file that has the fix for Oracle. If you replace the one you have with this one, it should work regardless of the cache setting. Let me know how it works out for you.
|
 |
|
jdev1 wrote:I found reason of my problem it's "topic.cache.enabled" in SystemGlobal.properties. When it's "true" it uses selectAllByForum with MAX.integer as argument that's why it was 2147483647 as value.
That addresses the symptom, not the problem. If I provide you with a version that includes the fix I posted above, would you be willing to test that?
|
 |
|
AN NPE sounds like some value is missing, so make sure all fields required for sending emails (basically, all fields above "Send a test email") have correct values in them.
|
 |
|
jdev1 wrote:I looked at the history of sql queries in Oracle and saw that when executing the query Topic Model.selectAllByForumByLimit variables for the block "WHERE LINENUM >= ? AND LINENUM < ?" 0 and 2147483647 are passed.
The value 2147483647 interesting, that sounds suspiciously like "-1", as used in GenericTopicDAO.selectAllByForum, and should cause TopicModel.selectAllByForum to be used rather than TopicModel.selectAllByForumByLimit. That is an optimization which apparently was never fixed for the Oracle code.
I think this is what should be in OracleTopicDAO:
@Override public List<Topic> selectAllByForumByLimit (final int forumId, final int startFrom, final int count)
{
if (count < 0)
return super.selectAllByForumByLimit(forumId, startFrom, count);
else
return super.selectAllByForumByLimit(forumId, startFrom, startFrom + count);
}
|
 |
|
No, it should be TopicModel.selectAllByForumByLimit in oracle.sql
I don't recall when selectAllByForum is executed, and when selectAllByForumByLimit, but only the latter one is overridden for Oracle.
|
 |
|
|
 |
|
|
 |
|
Actually, the software does scale the image down if it is too large, so no change is needed. Not sure what's going on with this server, but it seems JForum does the right thing.
|
 |
|
Thanks for the patch, I've just committed it (minus a bug that caused an exception if the number of results on the last page wasn't the same as the number of topics per page).
|
 |
|
The base problem seems to be that the first page shows all 35 results, when it should only be showing 15.
So yes, that looks like a bug. I'll put it on my list.
|
 |
|