June 4, 2018 in Developer Connection
Should I be doing a flood control check for all forms? While glancing through IPS ones, so far I only see it done in relation to editor inputs and I noticed of course some check related to searching.
I assume for searching, it will automatically take care of that for us. In past versions, I set up my own flood control and I think I generally used it on some forms and searching, myself.
The only actual flood control method I see, so far, though, specifically checks last post, so it obviously wouldn't be relevant to other apps if used exactly as it is now. We can't really use member_last_post ourselves, for this purpose, can we? Isn't that tied to stats related specifically to posting in a topic? Would be extra nice if a column were used only in relation to flood control, that we could update. Which, obviously not that hard to add a column myself, but anyway. I've never been sure how important flood control for forms is. I just figured form submitting, like searching, is a situation where someone can cause a tad more annoyance with constant submitting to lock up tables etc...
This is a business logic decision only you can answer. We don't have flood control on every single form; we add it when we feel there's a legitimate need.
ok, I just also was confused about it seemingly done in the editor form elements, whereas I would have thought it would be checked either before form display or during the actual $values = $form->values check to give a general form->error. But I havent played with it, so maybe it's obvious once I test it.
Was I wrong that member_last_post was for mroe than flood control concerns? Searching in the files, I don't see that in any html template, so it must not be the column used to actually "list" last post info, after all? Looks to me like it's for flood control.
member_last_post stores the member's last post timestamp. It's used for several things (flood control, bulk mail/group promotion filters, AdminCP stats, and so on).
I guess I should make my own column, but since it's recommended not to add a column to the members table, that will be a tad of a mess. I guess on upgrade I will make a new row in my new table (member stats table) and then use MemberSync to create one for new members and then add the flood control column there. Although, since I have seen that existing column used for different types of posting, I assume it still wouldn't create a problem using that one. If it's used for stats, it already couldn't be a stat based on last actual post in a topic, due to it not always used that way, I assume.
This topic is now archived and is closed to further replies.
Started 43 minutes ago
Started Thursday at 01:08 PM
Started November 17