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
5851
Features / Re: New revs - Public comments
« on October 17th, 2011, 09:50 PM »
Allowing a third party login system to be able to admin the forum is a security risk.

But all the third party logins should really create a true forum account, in which case whatever auth method can bootstrap the reminder process; OpenID had its own reminder page to remind you what OpenID login you used.

LDAP is something I thought about actually but even then you'd still authenticate against the LDAP server (eg Windows Server Active Directory) then create a forum account if necessary as the old LDAP bridge did.
5852
Plugins / Re: Plugin servers / getting plugins to a system
« on October 17th, 2011, 09:38 PM »
But everywhere I know that offers mods also offers a package server...
5853
Plugins / Re: Plugin servers / getting plugins to a system
« on October 17th, 2011, 06:37 PM »
More to the point, neither have I, and I think I can safely (and very legitimately) say I know SMF's package system better than most people. In fact, I'm still not entirely clear what actual use it does have. If something is serving packages through URL, you either download it to your PC and upload it, or it's going to be a package server anyway.

The *only* scenario I can envisage is for the case of a package not on a package server and you're using a phone to add a plugin. Which, frankly, is asking for trouble anyway.
5854
Plugins / Re: Plugin servers / getting plugins to a system
« on October 17th, 2011, 06:24 PM »
OK, so one page then. Question of the day: does anyone actually use the 'download by URL' option?
5855
Plugins / Re: Plugin servers / getting plugins to a system
« on October 17th, 2011, 05:25 PM »
I'm really not that enthusiastic about putting a jQuery widget in for something like that. For uploading multiple plugins, maybe, but anything more than that is IMO unnecessary, as this is something I don't want to spend vast amounts of time on, knowing that most users won't upload multiple plugins at once, probably won't even upload plugins all that often since it should be possible to handle from downloading better...
Quote
Sure.
OTOH, the only argument I have against this -- the plugin server would see a significant bandwidth increase if it can't server gzipped content...
Well... plugins would still be compressed, and you have to get to a largeish package before it makes a big difference. SD 2.0 for example is 553K for ZIP vs 404K for .tar.gz, and mostly that's because it has a lot of files in it, of which most won't compress all that well.

The other thing is preference. The majority of plugin authors are likely to be on Windows where making a .zip file is easier.[1]

The alternative is forcing .tar.gz across the board, which is smaller generally. Our plugin server could unpack zip and repack as tar.gz on upload. Those running custom servers would have to just deal with it, I guess.
Quote
I'd tend to put everything into the same page, but really that's because it's already the case in SMF.
Other than that... I don't really bother either way.
Well, if it remains as one page, it desperately needs renaming. I don't really have a problem with renaming it, just that my first instinct was to make it a separate page, but I'm increasingly agreeing with the view that it doesn't need to be.
Quote
It would have to be seen, first, if anyone creates 'independent' plugin servers that host plugins by multiple users.
Other than that, it'd be just simpler for us to provide RSS feeds on the Wedge plugin server with an author filter. i.e. people could be notified when their favorite authors release new plugins or new versions. Totally missing from the SMF customization site, eh...
Well, this is where it gets into the technicalities of providing support. I suggested doing it as a REST style but I don't think that's viable in the long run. In fact, I'm sensing it would have to pretty much be a SOAP-type request to the server to cope with everything.

What that ultimately means is that the requester sends an HTTP POST with the body being a block of XML. (Or POST vars. Doesn't really matter. The key point is that you make a POST with one or more variables attached.) Then you get a block of XML back in some form.

SOAP formalises this process, and I don't think we need go quite that far, but certainly it needs more than a simple URL request, since the process has to account for various kinds of filtering.
Quote
We could add a 'noob-friendly' option to do everything automatically.
If it fails --> manual processing.
I wasn't really going to do anything else. It's not like it's that hard to automate that process, especially since the user will have likely had to provide their FTP/SFTP details at some point (could even do it ahead of time so that the details are known before even trying to download)
 1. Don't flame me and tell me that it is or isn't easier on Linux. I honestly don't care. Most people here will be using Windows on the desktop, and it's directly built into the file manager and has been for years. I don't recall the same finesse on Linux distros.
5856
Features / Re: New revs - Public comments
« on October 17th, 2011, 05:12 PM »
Quote
Do you want to remove them, or me?
They can all go as far as I'm concerned. Even as a plugin I don't see OpenID as *replacing* the current login, but working alongside it. If FB Connect can be done as a plugin, so can OpenID, and FBC doesn't need the auth method setup AFAIK.
Quote
Yes/no. I have no idea, this hasn't been discussed in a while AFAIK.
Well, for the most part I was pretty happy to use it, and I was curious to know what you thought of it because it would require rewriting the more important queries to make them hookable directly.
Quote
Still, I'd like to know where I'm going to put the post-query hook
What, exactly, is it for? That's the question to ask. If it's for pushing things into $user_profile, it shouldn't be needed because $user_profile just gets the entire row as-is so providing it's in the query, it's pulled into PHP-land.
Quote
Not a big problem, I mean, we can always update them later... Or just don't bother.

PM example: the PM sender's name is specified with the group color. The PM recipient list isn't. Hmm...
I understand the logic of why it was done that way, it's primarily to avoid an extra query when that query (probably) isn't necessary, but it doesn't make it flexible. I'd almost be inclined to add an option in the admin panel for 'use member group colours', and make everything actually use that (doing the relevant join(s) to the membergroups table as appropriate). If nothing else, it's one more that's highly desirable that really, to me, should be in core.
Quote
Oh, and PT Sans + red for admin group = terribly ugly. Need to do something about that... Red is suitable for small Verdana fonts, but as soon as you make it a big font, it tends to catch attention too much.
*nods* I have no preference, but whatever is used, the rank images should adhere to it.
Quote
You mean, like specifying the list of fields we want...? Or maybe a 'thematic' load or something? Like, $set is too restrictive... It'd probably benefit from being turned into one big array where items are added individually after tests are performed (if (isset($set['sig']) $select_columns[] = 'mem.signature'...?)
And then in lMC we test whether said field is present before we process it.

I'd tend to say that lMD and lMC are two of the most important functions in Wedge, and they should be handled with special care.
Pretty much, at least. 'minimal', 'normal' and 'profile' are useful but not really *that* useful. Normal is used far more often than it's really needed to be, I find.

Now, if it were done thematically, you could really tighten up what's loaded when, though it would make bolting things into that query a lot more complicated.

I think figuring out where minimal and profile are used would be the first step, and making minimal a shade bigger to allow for things like member-group colour (and then making it used consistently!) would help - though I can't get the idea out of my head of splitting it into three to cope with the varied uses therein; places like PMs only need the minimal version, places like Display need the modest version and places like Profile need everything.
Quote
Removed in 1116.
Awesome.
Quote
Don't sweat it, that's what I'm here for...! It may take me a long time to go through your code changes but I always try to catch this kind of stuff... And I hope you do the same for me
I try to go through them, but I still miss stuff occasionally. Before our gold release, I'd like us to go through the language strings - at a minimum - to look for stray things that should have been removed.
Quote
Done in 1115, but what about %p..? We can't really transform AM to am magically... Unless we specifically try to do so...
Hrm. This smells like a partial reversion to me :/ If the format contains %p, I think we'll have to reinject am/pm instead.
Quote
I think I'm gonna go with the $txt solution where I provide the full year shortcut in the language files, and then if user doesn't use the default txt, we'll fall back to that test.
Works for me :)
5857
Features / Re: New revs - Public comments
« on October 17th, 2011, 03:52 PM »
Quote
I believe there are a few items remaining from the OpenID code... Not a lot really. Just a few lines.
Just search for 'authenticate' (single word) and 'auth_method'. Because the authentication method is only 'password' now, the variable is useless.
Odd, I searched for 'authenticate' and 'auth_method' but I guess I somehow missed those :/
Quote
On another note. I'm looking into loadMemberData() and it reminds me of the discussions about queries and making them hookable.
How about turning the stuff into something like this...?
I thought we were going to use something like Dragooon's wesqlQuery structure to make those hookable?
Quote
I'm thinking we should be adding a param to the function, telling Wedge not to bother with the 'heavy' processing and just fill in the blanks. I mean, if you have 50 users in the Memberlist, that means we potentially parse 50 signatures... for nothing!
Hmm. What I'd rather do is do the minimal stuff (user name/profile/group) and optionally then add extra stuff if needed, e.g. array('avatar', 'signature', 'custom fields'). Then I'd feel more comfortable extending loadMemberContext into general use (see in a moment).
Quote
And while we're at it -- I think it'd make sense to also have a param saying whether we want the member link to use group colors. They're not used in many areas and I'm not sure why. Actually, it could even make sense to always use the group colors. They're loaded at this point... Even in the topic pages it would make sense to show group colors (although I'm not sure about that.)
I've been wanting to add group colours for a while, just never got around to it. The real problem is that a surprising number of places do not reference loadMemberData/loadMemberContext for getting things like names, but do a raw join from whatever table into the members table to get the name. PMs is by far the worst offender for this from memory.

As I said above, it seems to me that making loadMemberContext more generally used would be advantageous, but at the same time that comes with an overhead in performance and memory. If it were better able to be segmented (both in lMC and lMD), as to what information you're looking for, that can be avoided.
Quote
- $txt['profile_of'] is used in things like $memberContext as a title. I'd rather have it say just 'View profile' than 'View profile of...' followed by a name that is *already* in the link... Totally silly. Plus, we already have $txt['profile_of_username'] which is correctly handled by a more logical sprintf.
Opinions?
Works for me. Is there anywhere $txt['profile_of'] is used as a link description where it wouldn't have the name available to it (and so wouldn't make sense if used that way)?
Quote
- $txt['time_am'] and $txt['time_pm']...
Crap, I thought I'd nailed all instances, guess I didn't search so thoroughly :/
Quote
I personally always type it in lowercase, and actually earlier versions of SMF used am and pm in lowercase, too, in timeformat()...)
'am' and 'pm' is probably nicer looking and more consistent with what everyone else seems to use.
Quote
I've written a more 'accurate' hack for the year removal. Please review it and tell me if that's okay. ($year_shortcut is a static array, while $format is simply =& $user_info['time_format'])
Looks fine to me.
5858
Plugins / Re: Plugin servers / getting plugins to a system
« on October 17th, 2011, 09:07 AM »
Well, I'm looking for general feedback on all of the above points, really, in terms of usability, practicality, that sort of thing.
5859
Features / Re: New revs - Public comments
« on October 17th, 2011, 08:53 AM »
I already fixed it locally going by the code in the bug report.
5860
Plugins / Re: Plugin servers / getting plugins to a system
« on October 17th, 2011, 12:55 AM »
Quote
The upload system wouldn't take up much screen real estate: would there really not be room for a "choose file" button at the top of the page?
Take a look how big the current download page is. It doesn't fit on the screen as it is, and it's going to get more complex in future, especially with the browse stuff being intentionally more prominent.

Plus, I do want to put some notes on the page about people uploading things manually (since there's little real difference, but some people are funny like that, and it's possible that the normal code won't be able to run for whatever reason, however unlikely)
Quote
In the case of the caching page, it's got options. A page consisting of a single button offers no choice, and I don't think most people would see a reason for the page to exist (particularly when there are other closely related pages it could be merged into).
A page consisting of a single button might not be too much use, but there must be at least two buttons (a pick-files and a submit button). I did also consider making it possible to upload multiple plugins at once should that be so desired.
5861
Plugins / Re: Plugin servers / getting plugins to a system
« on October 17th, 2011, 12:30 AM »
That makes sense, probably more than splitting them up, though the download process is likely to be more powerful than before, so I was also debating putting the whole 'package server' management into its own page, because it does need a shade more in future.

There is actually one page that does have so few things on it - the caching page. For most of the options therein, you don't get any configuration other than to pick caching type.

(Also, welcome to Wedge :))
5862
Plugins / Re: Plugin servers / getting plugins to a system
« on October 16th, 2011, 11:53 PM »
Bump for feedback. I've been doing work on other parts of the system that will feed into this... before long I'm going to have to implement this and would rather do it once and do it right...
5863
The Pub / [Archive] Re: Logo Madness
« on October 16th, 2011, 08:43 PM »
I do like the darker tint of simply-pete.

* Arantor is just fussy :P

In all seriousness, the logo currently in use here is pretty awesome. If we were to wait until both of us hit that 'aha' moment, we'd never achieve anything. You love the new one - stick with that! :)
5864
The Pub / [Archive] Re: Logo Madness
« on October 16th, 2011, 07:54 PM »
I think 'simply-pete' is my favourite of those. I've gotten attached to the drop-shadow look (and prefer that to the flat look), and I do like the blue over the green. Bright greens always remind me of feeling a little ill (whereas darker greens feel good and natural and warm to me)
5865
The Pub / [Archive] Re: Logo Madness
« on October 16th, 2011, 07:31 PM »
I like the logo, not quite as much as the brown/blue combination personally, but it still looks really good.