Wedge

I figured but wanted to be sure :)

(1 file, 1KB)

Revision: 1793
Author: arantor
Date: 15 December 2012 21:00:24
Message:
! Fixed generic list not being able to handle timeformat or comma format properly, though I did actually harmonise them entirely with the other types, and fixed the only instance I could actually find of using that. Suggested ages ago by Live but at the time I never understood the benefits or practicalities of it. (Groups.php, Subs-List.php)
----
Modified : /trunk/Sources/Groups.php

* Triggering the popup is easy. Create a rule that has moderate or prevent as its action, and you'll get an extra option at the bottom to put in a message for the different languages. Put something in there. This is so when a rule triggers, the admin can explain to users what they did wrong. The popup is just a convenience in the admin area to show the admin what all the different languages are. (I can add screenshots of the whole process if that would help)It was written that way, by me, deliberately back in February and it has *always* been that way since day 1. It's simply to not allow the user to actually add anything until there's something valid to add.No, it shouldn't, given that it only applies in two of the six possible things you can actually do in moderation filters. Locking/unlocking, pinning/unpinning do not trigger this message. Again, entirely by design.

As I see it, none of this is a bug. It's working exactly as I designed it to. Whether that means the design is wrong is a matter of debate, but if it changed, a lot more stuff has to be written to explain to the user what they're doing wrong. This way, they can't actually add a rule without conditions to it, they have to come up with a valid condition for a rule to add it to the rule and there must be a valid condition attached to be able to add the rule.It's still primarily used for the help text as far as I know (though the new say/ask might use it, haven't checked), and the only other uses are this popup and the who-liked-this popup, both of which are somewhat misappropriation of the help template by keeping the display logic inside the action itself rather than delegating it to some kind of template.

What I'm worried about is more people writing off Wedge (and other of the free platforms) because it doesn't match up to some theoretical ideal of how code should look. Enough people write off the free platforms as being 'toys' and not 'real' software as it is.

So, I've been reading up on vB 5, mostly out of the trainwreck mentality, and a bit of curiosity about how it's shaping up[1] and one of the things I've seen is commentary from developers doing a sort of peer review.

It also brings to mind a conversation I've had in the last couple of days, about coding style, where I said that a fair chunk of Wedge's code is written 'SMF style', which is a completely fair assessment from my perspective; Nao and I spent so long writing for/with SMF that it's not really surprising that it has shaped how we do things. There are some more modern things - there are more classes and things like exceptions in the newer code, but it doesn't change the fact that it's still carrying a lot of SMF structure and mentality to it.

Now, there are some interesting debates about OOP and procedural coding out there (and we are more OOP than the past) but my real point is... does it actually matter?

The only people who are going to see the code are the people who are going to modify the code, either directly or through a plugin - and of course us, in development and bug fixing. Whether something uses OOP or not should not be a concern for most people - and even for the people who do have a concern because they use the code, I'm not entirely sure most of them understand all the ramifications - heck, I'm not entirely sure I do some of the time.

Having classes to bundle functionality can be important. But it doesn't have to be as important as some of the pundits and reviewers say it is.

What I do know, and believe in, is using the right tool for the job. OOP is a tool, nothing more, but a lot of the 'but it isn't OOP' stuff seems to drift into the realms of 'when all you have is a hammer, every problem looks like a nail'. There's good OOP, there's bad OOP, just as there's good and bad procedural code, and we have a strange mish-mash, some of which we've inherited and some of which we've fixed.

But how many people care? As long as it works, does it actually matter that much?

/discuss

1.	The answer is badly. Even fresh installs are taking 60+ queries to do simple pages.

So, working on the whole nature of is_activated spawns a few ideas.

1) Purging users pending approval
One of the things that I hear regularly from other forum software is that users tend to delete users who haven't approved their email in a couple of days. To me, this makes a fair amount of sense, if a user hasn't activated their account within a day or so of signup, odds are they're not going to. So, it also makes sense to me, then, that after a day or so, we could automatically purge that for admins.

I don't see this causing significant extra load anywhere, nor do I see it causing any other problems at this time, but I'm opening the floor to discussions and thoughts on the subject.


2) User re-agreeing to agreement (required re-agreement)
This is something I've wanted to add for a while, and I mentioned it in my other topic. Mechanically all you'd do is take any user that already got approved (is_activated state 1) and update it to a new state (provisionally state 6) when the details change to force them to agree to it again, and since it's wired in at account level, they'd *have* to do it to continue.

The problem with this is the case of users who are not currently state 1, all the little fringe cases where their account is somewhere else:
* state 0 - user has signed up and in the time between signing up and approving their account, the terms changed
* state 2 - user is a current member but has changed their email address
* state 3 - user is waiting for admin approval, much like state 0, it's possible the terms changed between their registration and admin approval
* state 4 - user is waiting for account deletion, probably not a problem!
* state 5 - user is waiting for COPPA approval, this is probably the most likely problematic, a user subject to this is very likely going to have to wait some time to actually get their account approved as they would have to send the form through the post, and that makes it more likely to have changed

Actually now that I really think about it, all we really need to do is track their registration time against the time the agreement was last edited, and if they registered before the agreement changes, move their state to 6 rather than to 1. In fact, if we do it as a 'last change to status' column in general, that problem goes away in its entirety. Talking it through really does work!


3) We could drop the Location profile field and make it a custom profile field.
It's not a thing I've seen that much, dropping from the core and making it a CPF means it's not cluttering up the members table, and it's only in use if someone actually wants it on their forum, rather than being on by default and only able to softly disable it.

And you'd be quite happy running a public forum that has no working ban facilities at this time?