Wedge

I really think this should be implemented, especially as the hilarious comment from Nao from about 3 years ago hints.

Interesting one this, I'd always assumed there would be an error, but guess not.

In any case, I'd love to see if we can't do something better than using agreement.txt by default, simply because if you're going to modify it, you have to get into the realms of modifying the file itself rather than using the DB or similar.

Whatever we do with this, we should bear this in mind.

There's not really a good solution for this one, as indicated, because the password's going to be needed every hour, and I don't think for something like that, that it is reasonable to expect them to type the password in every hour.

I'm thinking a CLI script might be a better way to deal with that, but would encourage discussion on the matter.

I can see what's being said here - if you have a post that, when converted to get its br tags etc, will overflow 64K but the post itself was otherwise below 64K, it can be truncated at the end of the text boundary.

There was talk at one point that we were going to make it mediumtext, but the SQL says we didn't >_> Hmm, need to look this one up.

(4 files, 2KB)

Revision: 1406
Author: arantor
Date: 29 February 2012 11:10:33
Message:
! Cleaning up a language string in the admin. (ManagePlugins.template.php, Admin language file)

! SMF bug 4000/4730: Reattributing posts should also clean up the topics too. The query doesn't need to blindly reset every topic that the member owns, however, only the ones currently with a member id of 0. (Any that are actually otherwise wrong will be fixed by find/repair) (Subs-Members.php)
----
Modified : /trunk/Sources/Subs-Members.php
Modified : /trunk/Themes/default/ManagePlugins.template.php
Modified : /trunk/Themes/default/languages/Admin.english.php
Modified : /trunk/Themes/default/languages/Admin.french.php

I haven't digested everything here, but wanted to catch up on the most important points (to me at least)Yup, it certainly is. It needs to have query_see_topic somewhere, ideally the earlier the better.Ah, but it can. This is one of the many foibles of the system. If you have a topic that is unapproved, the owner and moderators/approvers can see it. Should a moderator/approver reply to it (e.g. in response to the opening post, as per SMF Showcase board), that post will be approved, but the topic as a whole and its opening post will both be marked unapproved.That's the thing, when you have two instances of the messages table aliased, it's normally because both the first and last message in the topic are being referenced, (e.g. message index pulls both the first post for the subject and topic starter, and the last post for the last poster's name and post time) and both of those could be separately approved or not.The point is, while I can't bring any examples immediately to mind, it's possible that someone can find a combination of ' and " that would allow them to escape out of the usual protective layers, so that malicious links or onclicks could be added.

I'd noticed that, heh.

The main fix, primarily, though would be to simply have the fatal error handler dropping everything inside default and only using its own template. Would likely fix the other mentioned issue too.

OK, so I'm fixing up the calendar at last, and there's the grisly assortment of mismatches of variables and things out of scope where they were before in the original code and I forgot to preserve it.

But, interestingly, I got this to happen.

The top template, as you might recognise, is the fatal error template. The theory is that it should normally override everything and anything. But it's called with a simple wetem::load, and as it happens in this case, another wetem::load has already been issued before we get to the actual fatal_lang_error call.

I'm inclined to think that the fatal error should override and remove anything in the default layer rather than the current prepending behaviour.

Thoughts (Nao especially)?