Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Arantor
4801
The Pub / Re: Trying something a bit new
« on February 24th, 2012, 03:29 PM »
And there's no images either, it's all CSS gradients (not even inheriting the normal gradient classes)
It is experimental, though, so it's ugly coding for now, but I did manage at one point to do a "#id reset extends something" which I thought was pretty neat :D
But it is also interesting to note where there is styling stuff hardcoded - the gap between the catbg and the titlebg bars in the screenshot is not controlled by the theme - but by a hardcoded div in the template. Same for the misaligned div in the thoughts area of the sidebar (where it's hard up against the left side)
Interestingly, it's not possible to truly replicate SMF's Core layout without changing templates, because there's no way I could find to wrap both the upper sections (the blue gradient area, the title area) with the navigation menu inside a single element, to get a border around both at once, because they're contained in two separate divs and the only parent is #wedge which contains the entire page.
As it turns out, I'm not that fussed personally, because I think the style I have there works better. Though I do want to see if I can't recreate something akin to SMF's Core menu tab thing, since I quite liked that. We'll see, busy seeing how badly the world looks on an iPod touch right now.
It is experimental, though, so it's ugly coding for now, but I did manage at one point to do a "#id reset extends something" which I thought was pretty neat :D
But it is also interesting to note where there is styling stuff hardcoded - the gap between the catbg and the titlebg bars in the screenshot is not controlled by the theme - but by a hardcoded div in the template. Same for the misaligned div in the thoughts area of the sidebar (where it's hard up against the left side)
Interestingly, it's not possible to truly replicate SMF's Core layout without changing templates, because there's no way I could find to wrap both the upper sections (the blue gradient area, the title area) with the navigation menu inside a single element, to get a border around both at once, because they're contained in two separate divs and the only parent is #wedge which contains the entire page.
As it turns out, I'm not that fussed personally, because I think the style I have there works better. Though I do want to see if I can't recreate something akin to SMF's Core menu tab thing, since I quite liked that. We'll see, busy seeing how badly the world looks on an iPod touch right now.
4802
Off-topic / Re: New here!
« on February 24th, 2012, 02:53 PM »
Yup, it's about martial arts, of course >_>
4803
The Pub / Re: Trying something a bit new
« on February 24th, 2012, 02:48 PM »
It's inherited from the current default skin ;)
4804
The Pub / Trying something a bit new
« on February 24th, 2012, 02:45 AM »
I'm no designer, and I generally leave theme design to others, but this one I thought I'd start trying to do something interesting. It's a WIP, dubbed Wintage. Might be familiar to some of you :whistle:
4805
Features / Re: Badges and the displaying thereof
« on February 23rd, 2012, 09:13 PM »
A badge is the same thing as a star, just you use 1 of them and use a bigger picture, but in all other respects it's the same thing.
The name of only the primary member group and the name of the post count group are the ones displayed, and the post count group can be hidden if there's a primary member group assigned (this is basic SMF functionality) - if it's shoeing every group, you have a mod added.
This stuff, though, is exactly what I'm trying to figure out.
The name of only the primary member group and the name of the post count group are the ones displayed, and the post count group can be hidden if there's a primary member group assigned (this is basic SMF functionality) - if it's shoeing every group, you have a mod added.
This stuff, though, is exactly what I'm trying to figure out.
4806
Features / Badges and the displaying thereof
« on February 23rd, 2012, 06:54 PM »
In the midst of discussions about privacy, we were discussing the way the Local Moderator / Board Moderator group's badge is handled and the problems with it.[1]
Which leads me to this topic, the general state of play as far as displaying user badges goes.
Some people just want to display the badge of the main group, some people might want to display the main group + local moderator badge if appropriate, some the main group's badge plus post count stars. Some people even want lots of badges (e.g. if you're a developer + artist + doc writer, say, you might want badges for all three)
Nao mentioned that it would probably be hard to write as a plugin - certainly currently that's the case because extending the display area is generally a pain, but we can certainly put something in place to make it easier.
So, I want some feedback on what you use, what you'd like. Tell me how you have your sites set up, whether you like that approach or not, and also whether you use the mods out there for such things like Stars and Badges. :)
Which leads me to this topic, the general state of play as far as displaying user badges goes.
Some people just want to display the badge of the main group, some people might want to display the main group + local moderator badge if appropriate, some the main group's badge plus post count stars. Some people even want lots of badges (e.g. if you're a developer + artist + doc writer, say, you might want badges for all three)
Nao mentioned that it would probably be hard to write as a plugin - certainly currently that's the case because extending the display area is generally a pain, but we can certainly put something in place to make it easier.
So, I want some feedback on what you use, what you'd like. Tell me how you have your sites set up, whether you like that approach or not, and also whether you use the mods out there for such things like Stars and Badges. :)
| 1. | On this site, for example, in some of the boards I'm listed as a local moderator rather than my normal badge because I'm not in the admin group. There is special code in the loader for this specific purpose. |
4807
Features / Re: Privacy options
« on February 23rd, 2012, 06:45 PM »Because I'm feeling lost. And the more I talk about something, the less time I have to work on it
And it's going to cause many people to ask about it... Then we'll make a FAQ rule, that people won't read... Then you'll give up and add a master setting
There's already a moderation entry in the main admin settings menu, so we could have the master moderation setting there, something like "Enable Post Approval and Moderation Rules", maybe something shorter, and depending on that setting, we show the moderation filters menu or not... (Although it's likely that you'll want to have it very much in everyone's sight for starters, if only because it's a powerful new Wedge feature...) (Well, that could be a good opportunity to set post moderation by default.)
One possibility I just thought of, to make post mod faster... We keep a list of unapproved posts, right? I remember seeing that setting in the code I dabbled with this morning. Well, how about we simply add, in query_see_topic, a PHP check to see if there are any unapproved posts... If anything's found, add the t.approved code as needed. Otherwise, skip it!
In any case, doing what amounts to SELECT ... FROM topics WHERE id_topic NOT IN (list) is actually very slow. The indexes are very good at finding what's there, but not so good at finding what isn't there - instead of using the index, they have to go through and attempt to match each one. It isn't pretty. (Incidentally, it's why the stock implementation of ignore topics is so painful.)
Your logic itself is sound and very commendable. I'm more worried about our users' logic. And mine
I don't know -- just say you wanna test whether the filter is actually useful, so you disable it for a while, and if spam comes back or whatever, you re-enable it.
Or if a pre-moderated area is quite slow and you're going on vacation and want people to be able to post freely to it -- you disable it, until you come back and re-enable it without having to worry about re-entering a list of filters or whatever.
Then I think it should be 'acknowledged' at the very least, for instance in the rule settings, instead of 'Posting in...', have something like 'Creating new topic in...' or 'Sending new post in...'?
Your way of phrasing it is correct, it's just harder to understand on first use. It might be better with the suggestions I wrote above.
Yeah, I like them a lot eheh. I try and use them anywhere I can.
I noticed earlier today while making my commit, that I'd at some put put a query_see_topic at the beginning of a query instead of the end. Oops! I immediately moved it to the end, specifically because I figured it would be evaluated last and thus would be much less expensive. So I was right, right?
Yes, in many queries. But not all... Look at Recent.php, for instance. There are more like that. I left them as is because I figured we should discuss it first.
Oh, my... That again? Oh, I try not to touch these with a 10-foot pole...
So it's the opposite of what I thought, right...? I thought that people wouldn't be able to see the topics in the topic list, but would be able to access them by ID...
Then again, I'd tend to go to someone's membergroup and check permissions accordingly. But it's always unclear what moderate_forum does. Plus, SMF/Wedge tends to... be a bit lazy about it, and sometimes it adds allowedTo('moderate_forum') for something, where in other situations it won't...
* access to registration management
* access to the view/delete members screen
* extensive profile info, including track IP/user and (hidden) online status
* activate accounts
* get approval notifications and approve accounts
* immune to ignore PM
* several small things
If not, then there's no point in using extra tables and such... Imagine a whole world running on FIND_IN_SET... Lol, what a mess
Oh, and reminds me of something... Maybe, MAYBE we should allow for topic privacy to be respected even by admins... I mean, somehow, it's exactly like private messages, or PMs sent to multiple recipients (in the case of "contact-list-based topic privacy").
You think...? Because it would be run even if topic privacy is set to default... (Of course, it wouldn't return anything.)
Well, technically it couldn't be a left (or inner) join I think -- if it doesn't find anything, does it mean it's a public topic, or it's private but you can't access it...?
And I'm not even getting started on this forum I found through googling for 'wedge fork' a couple of days ago, 'anotheradminforum', where I was surprised to find you and a bunch of our members discussing Wedge and other things... And nobody even cared to tell me Of course, you *had* to post nearly 3000 posts over there in the last 4-5 months, which is more than your post output on wedge.org... And I thought you'd gone quieter over the end of the last year
Of course, I *suppose* you thought of that because of Wedge.org's current implementation -- you're thinking that it'd be simpler to just give 'View thought replies' permissions to Friends, and 'View thoughts' permissions to everyone else... Right?
The thing is, privacy controls are wonderful - but they're also complex, no matter how you do them, unless your interface is totally geared to it - which is why G+ got it quite right, because so much dev time and effort went on the interface. Meanwhile, for what is, proportionate to the actual act of posting in a forum, a minor feature - privacy on thoughts is a bit more complicated than perhaps it needs to be.
If I don't care whether people can see it, I'll post it as a thought. If I do care who can see it, I'll post it in the relevant board.
| 1. | Apologies to Kevin Smith. |
4808
Features / Re: Privacy options
« on February 23rd, 2012, 05:37 PM »I don't know. It screams "admin setting" to me, because some admins will want two badges, others will want to show moderator badges, and others like me will want to show regular badges if available...
Hmm yes, that's the way it should be. I think I meant moderate_forum per se, though. Does giving moderate_forum permission to someone, also give them implicitly (or explicitly through code I couldn't find), the issue_warning permission...?
Yay, a SMF bug
I'm giving up trying to understand what that group is meant to do/be...
There's a way about it, it's using the contact table Which we'll do, as it's already in the DB...
Well, I suppose we could add something in loadBoard... Check $topic, and if it's filled, add a query_see_topic?
Hmm... A relationship, you mean a comma separated list?
Hey, how about we keep a table with proper relationships...?
A table would be better but you still have to get the query running nicely, though having the option of subqueries should help.
Because topic privacy is unlikely to be used on a majority of topics, it would keep the table quite small. Maybe we could even get rid of any privacy fields in the topic table, and just do a LEFT JOIN but I don't think it's very practical to do, just a silly idea.
Hmm, so it's definitely a no-no...
I really, REALLY want to know what you drink or eat to be able to answer things so quickly and so thoroughly.
But I'm not sure it's any good. I mean, why would I would people to be able to view something or not? I want authors to be able to determine that themselves... They're the ones who should know whether they want a thought to be public or private.
4809
Features / Re: Privacy options
« on February 23rd, 2012, 05:29 PM »But how can I enable it, at all?
See, post moderation is not just about filtering new posts... It's also about being able to unapprove posts (something we're still not doing, AFAIK...), which we won't be able to do if this happens. How about adding a master setting to the filter page...? Plus, it would allow admins to disable their filters without having to delete them, if that's not possible right now.
As for disabling a filter without deleting it - why would you? Either it's not working for you and needs editing, or it is working and should be left alone.
BTW I went ahead and looked at the page. I was a bit confused with the order. For instance, you can change the 'new post' or 'new topic' item after making new rules. I think it'd be more understandable if it was disabled, or hidden and repeated as a simple text string in the next fieldset. Also, the 'posting in these boards' thing may be confusing as well. I know that my direct French translation made me feel unsure about it. I changed it to 'posté dans ces sections', meaning 'postED in these boards', but I'm not sure it's the best.
As for 'posting in these boards', I couldn't think of a better way to phrase it. I suppose past tense is more correct, but the idea is to convey the notion that if the post is made in one of the boards you're picking (or not, depending on situation), that the rule will apply.
Finally, it'd be nice to have slideDown animations, I think, instead of simple toggles. Perhaps a fade in for the "Save rule" button, because it's not always clear that the "Save filter" button is being hidden and replaced by another (even though the new one is inside the fieldset rather than outside). If it's going to be a wizard, it should be super-user-friendly, which right now I'm not sure it sure. I'd like to know your opinion on this.
But we always need a WHERE clause, I never met a single case where a post-mod test was being done and the WHERE was added only for it.
SELECT ... WHERE stuff is always going to outperform SELECT ... WHERE stuff AND m.approved... unless (and only unless) the stuff in the first place excludes everything anyway. If there are any rows found by the stuff clauses, they will have to be evaluated by m.approved.
See, this is what I don't get: I'm saying that SMF/Wedge has t.approved tests done *only* if postmod_active is enabled, while m.approved tests are done without testing for postmod_active first. It seems to me that m.approved is slower than t.approved (because of relative table sizes), so it should be the one with systematic postmod tests, not the other way around...
// Get each post and poster in this topic.
$request = wesql::query('
SELECT id_msg, id_member, modified_member, approved, poster_time
FROM {db_prefix}messages
WHERE id_topic = {int:current_topic}' . (!$settings['postmod_active'] || allowedTo('approve_posts') ? '' : (!empty($settings['db_mysql_group_by_fix']) ? '' : '
GROUP BY id_msg') . '
HAVING (approved = {int:is_approved}' . ($user_info['is_guest'] ? '' : ' OR id_member = {int:current_member}') . ')') . '
ORDER BY id_msg ' . ($ascending ? '' : 'DESC') . ($context['messages_per_page'] == -1 ? '' : '
LIMIT ' . $start . ', ' . $limit),
array(
'current_member' => $user_info['id'],
'current_topic' => $topic,
'is_approved' => 1,
'blank_id_member' => 0,
)
);That's in Display.php. That's the query that identifies what posts are to be displayed, everything after that shouldn't be filtering it.
Want me to look into it?
I'd be curious to know if this happens in stock SMF installs. I can't do it for my sites because they all use my custom code, but to anyone with a forum: please enable post moderation, post an unapproved topic, and use a low-level account to access it directly by ID... Does it show you the topic? What about the post itself?
4810
Features / Re: Privacy options
« on February 23rd, 2012, 04:02 PM »Well, that's what I'm saying: it is... It's tested whatever the postmod_active state.
BTW, where the hell do I enable postmod?! Now that core features are gone... Well, I even made an admin search and didn't find any 'master' setting?!
...I don't get it. If testing for m.approved=0, m.approved=1 or nothing at all, same performance. How can it be, since in the last case we're sure not to ever use the approved index...?
Hmm... That does seem like something that might confuse people. It confuses even me...
Is it working, at least? Last time you didn't have the Save feature for it, so I left it aside but now I need to have postmod enabled just to test my code...
Heck, can anyone actually view an unapproved topic if they don't have permission to, but they know its ID? Because I can't see any code to stop them in Display.php! Actually noisen.com/wedge.org do have such code, that's where it gets funny. Well, they don't add approved flags to the mix but at least they support 'justme' privacy.
I know in SMF if you have a topic whose ID you know but it's moderated, you can only see it if you're the owner or a moderator with suitable permissions, but it's enforced by loadBoard as far as I can tell, not by Display. Display assumes to a point that if you can see the board, you can see the topic.
4811
Features / Re: Privacy options
« on February 23rd, 2012, 03:41 PM »Well, if it's turned off, m.approved should no longer be tested against, should it...?
...Unless you never enable it..?
Is it enabled by default in here?
However, I foresee people using it in all kinds of funky ways, and as such I think it's likely to be 'on' (in SMF terms) more often.
4812
Features / Re: New revs
« on February 23rd, 2012, 01:47 PM »
(7 files, 5KB)
Revision: 1379
Author: arantor
Date: 23 February 2012 12:46:21
Message:
! Subscriptions should be able to be configured for lifetime access. It's a surprising amount of work but I think I got everything straightened out, needs more testing of course. (ManagePaid.php, Profile-Actions.php, ScheduledTasks.php, subscriptions.php, Subscriptions-PayPal.php, ManagePaid.template.php, ManagePaid language file)
! slideToggle() doesn't work the same as toggle(), can't use it to set the final state. (ManagePaid.template.php)
! Encoding fix (just ManagePaid.english.php - French file is fine)
----
Modified : /trunk/Sources/ManagePaid.php
Modified : /trunk/Sources/Profile-Actions.php
Modified : /trunk/Sources/ScheduledTasks.php
Modified : /trunk/Sources/Subscriptions-PayPal.php
Modified : /trunk/Themes/default/ManagePaid.template.php
Modified : /trunk/Themes/default/languages/ManagePaid.english.php
Modified : /trunk/subscriptions.php
Revision: 1379
Author: arantor
Date: 23 February 2012 12:46:21
Message:
! Subscriptions should be able to be configured for lifetime access. It's a surprising amount of work but I think I got everything straightened out, needs more testing of course. (ManagePaid.php, Profile-Actions.php, ScheduledTasks.php, subscriptions.php, Subscriptions-PayPal.php, ManagePaid.template.php, ManagePaid language file)
! slideToggle() doesn't work the same as toggle(), can't use it to set the final state. (ManagePaid.template.php)
! Encoding fix (just ManagePaid.english.php - French file is fine)
----
Modified : /trunk/Sources/ManagePaid.php
Modified : /trunk/Sources/Profile-Actions.php
Modified : /trunk/Sources/ScheduledTasks.php
Modified : /trunk/Sources/Subscriptions-PayPal.php
Modified : /trunk/Themes/default/ManagePaid.template.php
Modified : /trunk/Themes/default/languages/ManagePaid.english.php
Modified : /trunk/subscriptions.php
4813
Features / Re: Privacy options
« on February 23rd, 2012, 12:02 PM »
Sadly, no. If it never checks for being enabled or not, but always checks anyway, there's a performance hit attached. It's just not one you can avoid by turning the feature off...
That's really more of an SMF issue; in their case, post moderation is a very specific feature, disabled by default, so you get penalised by default whether you use it or not.
In our case, I'm really expecting users to use it more than SMF users make use of post moderation, meaning that while you're still getting penalised for that query overhead, at least it's done mindfully of the fact that moderation is likely to be in place.
That's really more of an SMF issue; in their case, post moderation is a very specific feature, disabled by default, so you get penalised by default whether you use it or not.
In our case, I'm really expecting users to use it more than SMF users make use of post moderation, meaning that while you're still getting penalised for that query overhead, at least it's done mindfully of the fact that moderation is likely to be in place.
4814
Features / Re: Privacy options
« on February 23rd, 2012, 11:45 AM »
Actually, it's only a problem since I messed with it. In the old code, disabling post moderation would actually silently force everything unapproved to become approved. Now it's a discrete option you have to use should you want to do so - but the odds of that happening are actually surprisingly slim (since it requires removing every moderation filter not just ones that trigger moderation)
4815
Plugins / Re: Edit History
« on February 23rd, 2012, 11:24 AM »
I really wouldn't worry about changing it. I don't see many people changing it, and those that do... they're going to change it in a less dramatic way than I have (i.e. the same string each time)
Honestly, I'm more bothered by the fact that quote/modify aren't directly extensible than I am about trying to extend the menus.Quote The algorithm is extremely complex. I narrowed down the segment of code I want, but it's about 20K of code that's complicated to unravel, especially when one loop, for example is set up as such:
Code: [Select]
Don't worry about what all the variables are, just consider how complex that piece of code is for what it's actually doing. (It's used to go from the end of the before/after pages, from whichever's shortest and traverse back up towards the $skip point, which is the location of the earliest line of difference)
Honestly, I'm more bothered by the fact that quote/modify aren't directly extensible than I am about trying to extend the menus.
As for MediaWiki, the code is GPL but the concept/implementation algorithm isn't. Surely you can get inspired by it?
for ($endskip = 0; --$xi > $skip && --$yi > $skip; $endskip++) {Don't worry about what all the variables are, just consider how complex that piece of code is for what it's actually doing. (It's used to go from the end of the before/after pages, from whichever's shortest and traverse back up towards the $skip point, which is the location of the earliest line of difference)