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
5836
Features / Re: New revs
« on October 18th, 2011, 04:13 PM »
(303KB[1], added 2, modified 4)

Revision: 1118
Author: arantor
Date: 15:10:30, 18 October 2011
Message:
! Fix for QueryString not urldecoding as it should (thanks TE) (QueryString.php)

! Missing hooks should have been declared in plugin manager (ManagePlugins.php)

! Part of the works for supporting file permission changes in the plugin manager. It's horribly unfinished right now but I want to commit it because even right now it's actually an improvement on where we were - for cases where FTP/SFTP is not required, it actually works properly in being able to recursively delete things, and it has been built in such a way that extending it to FTP/SFTP shouldn't be a slog; I've actually designed it around having file-changing classes that it should be able to interchangably use, Class-FileWritable for locally writable cases (though it doesn't use that as thoroughly as it should, it should be checking the entire permissions of every file/dir under consideration, not just the first level!), Class-FTP or Class-SFTP for where S/FTP connectivity is needed. Class-SFTP has not been tested since I made my changes to phpseclib, so it's probably broken too - or it might be, if I actually put in the relevant dialogue, which I haven't yet. Just wanted to get something committed where it actually works in a meaningful way compared to what it was before! This is, then, very much still a WIP. (Don't worry about reviewing Class-SFTP at this stage...) (ManagePlugins.php, Subs-Plugins.php, ManagePlugins language file, ManagePlugins.template.php, Class-FileWritable.php, Class-SFTP.php)
----
Added : /trunk/Sources/Class-FileWritable.php
Added : /trunk/Sources/Class-SFTP.php
Modified : /trunk/Sources/ManagePlugins.php
Modified : /trunk/Sources/QueryString.php
Modified : /trunk/Themes/default/ManagePlugins.template.php
Modified : /trunk/Themes/default/languages/ManagePlugins.english.php

@ Yeah, this is probably a bit earlier than it should have been, but a few notes on the design of it. The idea is that getWritableObject() is essentially the same construct as create_chmod_control but without having to be so formal about it. Either it'll return you a usable object with which you can do file operations, or it'll take you to a dialogue to enter S/FTP connection details. Or it would if the dialogue was any more than a placeholder.

It is still incredibly raw but it's getting there.
 1. As noted in the changelog the vast bulk of this is Class-SFTP, which doesn't need reviewing at this time unless you're feeling very, very brave. It's probably slightly broken anyway.
5837
The Pub / [Archive] Re: Logo Madness
« on October 18th, 2011, 03:23 PM »
Quote from Nao on October 18th, 2011, 03:12 PM
The sidebar logo is wedgelevelf, not wedgelogof ;)
Not according to post 748: :P
Quote from Nao on October 18th, 2011, 01:35 PM
I've updated post #722 with more logos.
- wedgelogof is the current sidebar logo (still my favorite)...
Quote
Sorry for all the silly filenames... My FTP connection usually logs me out after like 20 seconds of inactivity and it's very slow to navigate the top-level folder (because of the hundreds of files it has), so when I get to upload new files, I usually think of renaming them at the last moment and there you go, I can only think of stupid names in a few seconds ;)
Hrm, not sure what to suggest about that, other than putting it in another folder somewhere, and using SFTP rather than FTP (which expressly doesn't have the concept of chdir, you just set an absolute location instead)
5838
Plugins / Re: Personal plugin showcase (yes, I'm an attention grabbing git)
« on October 18th, 2011, 03:20 PM »
Yeah, that's something I meant to do but the starting list was generated by doing a search on call_hook and going through the results. I must have missed a couple as I went.
5839
Features / Re: New revs - Public comments
« on October 18th, 2011, 03:19 PM »
Quote
Then should I revert my changes...? Just to be sure. What about passing params? (I suspect you discuss it below...)
The discussion on wesqlQuery showed examples of doing that, no?
Quote
Can you elaborate on this...?
I've rewritten my code to store members+groups followed with a list of colors per group, to avoid repetition and thus generate a smaller cache file for bigger arrays. But I'm not sure what you're suggesting...?
I figured we might as well cache the membergroups and their colours generally (including post count groups), and in places we already do a join to the members table to get the member's name, add the id_group and id_post_group parameters from there into the query.

The idea is to save either the extra join or the extra query, since if we're already doing the join to members, there's no need to do any further joining or querying if we already have the list of membergroups and their colours available to us.
Quote
Sorry, I don't mean that I don't understand them, I just mean that I don't get the point. To me, output buffers are nice if you're trying to 'catch' data output by something else, etc, but if you know the exact execution order, it's best to just put everything into the same OB...
For instance, link replacements have to happen after <URL> is transformed, but before pretty URLs are applied. I was thinking of using my replacement code right inside the purl filter file, to be able to both transform profile URLs and add a color at the same time, but... Err, one millisecond...? Who cares. Might as well make the code clearer and put everything in the same place.
The argument I'm suggesting - but not that heavily - is encapsulating functionality. Right now the post-replace phase is pretty complex, and is made up of a series of stages. Wouldn't it be better to make each stage a separate function, so that if ever you need to alter behaviour, firstly it's localised into a single function, and secondly if you need to rearrange them, you're rearranging a few lines rather than bulk copy/paste?
Quote
Sure.......................... Who's up for it?
I kind of like the columns on here/Noisen actually, it's an improvement over the default. I also hear that what Antechinus made for the 'dynamic memberlist' isn't too bad either, might be worth looking at the visual side to see if it isn't hideous and see whether something vaguely like that wouldn't be a bad idea.[1]
Quote
What do you mean?
Atom is XML. If you add an attribute to that XML, it's still valid XML - but it stops being a valid Atom file. Remember, XML formats aren't just randomly extensible, they have schemas to direct what elements there are and what the valid list of attributes is.

Some XML consumers won't care and will totally ignore that attribute. Some will care a great deal and write the XML feed off as invalid. So yeah, it's kind of important not to just randomly mess with set XML formats unless you're the only one using it and can afford not to be too picky about it come consumption time. For example, the plugin manager doesn't ever expressly validate the plugin-info.xml files against the schema. It *can* but it doesn't. It only validates the content to make sure it makes sense and is understandable, not that it's strictly legal. (I figure we'll do that on plugin upload, you see)
Quote
(With the technicality of big user names (e.g. userbox authors) being potentially a problem. I'm thinking of fixing it by changing the default colors to pastel ones, like the group colors on wedge.org... #d2653a is definitely nicer than red for admins!)
*nods* I don't have a problem with that, I think it would be an improvement.
Quote
Looking at the SMF2 code, it only checks for %p (lowercase), which generates uppercase AM and PM, and manually transforms them to time_am and time_pm, but they're not dealing with %P... Just so you know-- if you add a %P on a server that doesn't support it, it'll return an empty string... Not an empty am/pm; but an entirely empty string. (At least under Windows.) I don't think 'wrong' values are being filtered out if the user enters a custom time format...

(Heck, if it wasn't for the custom time format thing, I wouldn't have had to do the whole preg_match stuff to find the year.)
No, Windows doesn't do any filtering, which is a bit poor really. (It should at least return them as literals.)
Quote
<evil grin> "I don't know, but it's going to be a lot of fun finding out!"
Actually, Dragooon answered that one, and wesqlQuery provides for it.

 1. But I'd code it from scratch anyway, not only to avoid claims of copying but simply because we'd have to do it differently.
5840
The Pub / [Archive] Re: Logo Madness
« on October 18th, 2011, 03:08 PM »
Quote
@Pete> That one isn't in the list..?
You said that was the one currently in the sidebar... that's the one I like most compared to the other options that are there - but I can't tell you for why exactly.
5841
Plugins / Re: Personal plugin showcase (yes, I'm an attention grabbing git)
« on October 18th, 2011, 02:34 PM »
Yeah, it's a fairly simple enough test: get all the hooks we know and see if a plugin requests any we don't know :P But that doesn't help if not all the ones actually in Wedge aren't listed. Guess I'll have to check that again :/
5842
The Pub / [Archive] Re: Logo Madness
« on October 18th, 2011, 01:59 PM »
* Arantor is still rooting for wedgelogof to be honest...
5843
Plugins / Re: Personal plugin showcase (yes, I'm an attention grabbing git)
« on October 18th, 2011, 01:18 PM »
Hrm. It seems I missed adding both hooks to the list of known hooks for some reason.

At the end of ManagePlugins.php is a list of what is supposed to be all the hooks in Wedge's core. just add those two to the list and it'll allow you to use them.

I'll fix my local copy so it can be committed in future.
5844
Features / Re: New revs - Public comments
« on October 18th, 2011, 09:25 AM »
Quote
Well, if you and Dragooon are into it, then you should do it... I don't have the perfect answer to everything
It's on my todo list :P
Quote
Or, as I said: select m.id_member, g.online_color from members as m, membergroups as g where m.id_group = g.id_group
Something like that... (?)
Yes, but it means doing that treatment everywhere where names are pulled directly. The alternatives are converting everything to a case of loadMemberData (minimal) or doing it in the post-replace phase, either way that's an extra query.
Quote
Then get the entire list of people, push it into the cache for a few minutes, and use that cache internally to associate people with a color. It might represent a large cache file but if we ensure the option can be disabled, it's okay I guess... (?)
Hmm. I'm thinking that we could do it better by querying and caching the member group colours on a longer term basis, and fetching user+group instead, as querying every user with their group is going to be quite expensive.
Quote
Why? I can't think of an example where adding a class to an anchor would be detrimental to XML functionality...?
It depends how fussy the receiver is. A receiver expecting Atom and gets not-strictly-valid Atom might throw a wobbly. Besides, in XML modes, there's no point running that operation, might as well save a few CPU cycles...
Quote
Hmm yeah, I suppose... Although it's unlikely to happen.
But we could look through the entire anchor tag and reject it if it has bbc_ in it or something...
Works for me. Just something I wanted to be careful of, really.
Quote
Definitely cleaner. But easier to understand? I don't know, I've never been much into 'nested' output buffers, they never made much of a sense to me, I'd rather have it all in the same place...
It works like any other nesting, and for the most part it's pretty transparent. The buffer's passed in with each successive nesting, callback run when the buffer's done, then it's passed back up the nesting.
Quote
Well, we could simply turn these into sub-functions and call them all from ob_sessrewrite...
That would work and would probably be faster than using true buffers to pass back and forth.
Quote
Or 'custom', in my mind.
If you're sending out a feed of new members, there's really only so much you can put into it before you break Atom format, no?
Quote
Definitely a 'custom' candidate then...
Memberlist is definitely a custom candidate. We need to decide what columns are actually needed.
Quote
It only uses lMD when you're setting PM options in your profile...
That seems... illogical somehow.
Quote
I'll let you check the files independently... Yeah IIRC it's to find usernames for recipients that didn't go through the auto-suggest.
Ahhhh, loadMemberData with second parameter as true, that makes sense now.
Quote
I think that's the only place you get it apart from the info center... A real bummer.
Yup, it either should be throughout or not at all.
Quote
It's technically valid only in Linux. It doesn't work in Windows and Mac OS.
That'll be why I didn't think of it.
Quote
You know, you COULD revert this and no one would blame you for that...
I could but it would feel wrong. The whole solution seems hacky and I don't like it but I just don't know a better one.
Quote
I suspect that means something you offered before, sorry I can't remember.
I just looked at the huge query, remembered the hassle it was to plug some of AeMe's code into it (one of the biggest incompatibility generators out there), and wanted it gone, like, now.

Also, btw, I'm not sure wesqlQuery allows passing extra parameters not related to the query itself...?

Like, new wesqlQuery('hook_name', (query stuff), array($set, &$users, &$is_name))...?
There was a discussion on sm.org where someone offered a patch that did almost the exact same thing.

Also, why would you want to pass in parameters not related to the query itself, exactly?
Quote
yep, that's a perfect solution regarding admin security but there would still be an issue with the profile account data (can't be updated because I don't know my password). Maybe I can set that field as a hidden form field with a pre-filled password or something similar.. I currently have no clue to work around that issue with a proper solution..  Any ideas?
There was some stuff in the profile code relating to this for OpenID purposes, actually. There's a parameter 'password' that's needed to be set if password is going to be required for changing, IIRC, which was set to false if OpenID was used. But OpenID wasn't capable of taking any case where validatePassword was called (which meant you couldn't go into the admin panel, or change someone else's profile, though you could change your own because of the above)

It wouldn't be too bad to provide somewhere that that value can be reset through a hook, and optionally a hook in the validatePassword subsystem to allow authentication plugins to safely handle admin-type security checks.
5845
Features / Re: New revs - Public comments
« on October 18th, 2011, 08:56 AM »
Authenticating to a specific third party under your control is one thing, authenticating to a separate third party that you have absolutely no control over is something else.

The former is one place where I can see the logic, though surely all that's needed in that case is to turn over authentication over to the separate backend and if authenticated through that method, silently turn on 'disable admin security' (but only for the life of that page)?
5846
Features / Re: New revs - Public comments
« on October 18th, 2011, 01:34 AM »
Quote
That looks familiar...
There are only so many ways you can make that beast hookable in its present form. Hardly surprising that both we and folks on sm.org were discussing it (theoretically independently) at the same time. Had I seen discussion there about bootstrapping a query object around it like we already talked about (and publicly), then I'd suggest all was not well in the garden of plenty. But hooking it conventionally... not so amazing.
5847
Features / Re: New revs - Public comments
« on October 18th, 2011, 12:13 AM »
OK, so for the rest of the stuff...
Quote
Yeah... Makes sense. But considering the user won't have to choose a password (because all of this will be handled by OpenID or Facebook...), there are a few things that will still need to be added or removed... e.g. the password reminder won't work.
See above. The reminder functionality should be rediverted to however the plugin wants to support it.
Quote
My opinion...? Too complicated. I read through the topic and then I forgot it all.
I suppose that given we won't use this in all queries, it's okay to use it. But I'm not the one who'll implement it
Heh, that's really why I wanted your input since it would require converting queries and 'big' queries would need this treatment later.
Quote
An extra query are you sure? I have a feeling everything can be done with a LEFT JOIN on the membergroups table...
That's precisely my point. There are two routes: bolt on the left join on top of everything, every single place where member names are pulled directly (and trust me, there's a lot), or route it through loadMemberData which is an extra query.

Ideally everything should have gone through lMD/lMC for consistency but it's not done that way for performance.
Quote
I was thinking... Maybe, *maybe* we could 'simply' have ob_sessrewrite look through the list of links and color them accordingly... i.e. it gets the profile ID from the link, then fetches a list of users and groups. We'd just need to get a (cacheable!) list of membergroups and associated IDs. Then we can build a list of colors associated with member IDs. And voilà. We simply inject the needed CSS at rewrite time...
Works for me. But note that it's essentially the same query that I mentioned above, just run at a different time.

There are some interesting side-effects to doing that in the replace hook to beware of. Firstly, we'd have to disengage it if XML output is being used. Secondly, if there's a link in the middle of a post or something to someone's profile, that's going to be hit too.

Also, I'm wondering whether it wouldn't be cleaner[1] to put the different replace processes in their own buffer, to be called at the appropriate time. Just for the sake of putting code together and making it easier to follow (as opposed to one monolith function that makes it harder to understand, especially since its original purpose is slowly being outweighed by all its extra work)
Quote
- profile: used in PersonalMessages.php when editing PM settings in the profile area, for use in the subsequently called saveProfileFields(), and in Profile and Profile-Modify, as expected.
*nods* Profiles do actually need everything.
Quote
* used in SSI (ssi_queryMembers), Display (load post authors), Feed (getXmlProfile), Memberlist (load member list -- serious candidate for 'minimal'), PersonalMessage (used in MessageFolder to load PM authors, MessageSearch2 for the same, MessagePost, and drafts. Used in Aeva Media's admin page to list moderators (strong candidate for deletion.)
SSI use makes sense, though it could become a 'minimal' use without too much effort IIRC.

Display - naturally needs to be pretty thorough given what's displayed.

Feed - should be minimal, right?

Memberlist - it sort of depends what we put in the memberlist, and whether we add things like custom profile fields and avatars. (I've been meaning to add an option to CPFs to display in the memberlist, but I keep also meaning to think about doing something with its layout and making it less sterile)

PM - it uses lMD? I'm surprised, I'd actually thought there wasn't a use within PMs to do so, especially given how many other places within the PMs *don't* use it.[2]

Post I can understand for displaying the form back to users, but I don't remember it in drafts. There must have been a reason, very likely to find usernames, but I don't remember.
Quote
* Used in Search2 to get authors for found posts. Used in Who.php for the Who's Online list. Another candidate for 'minimal'...
Yup, though it's nice having the member's name in the right colour there as it should currently be.
Quote
I think there will be some, yeah... It's bound to happen. But I'd rather have too many strings than not enough
Sure, but I'd rather have the *right* strings for the job, even if that means adding or stripping some.
Quote
I'm not sure I understand. AFAIK SMF has always used %p to show the am/pm bit... Even Wedge uses %H:%I %p everywhere (in English). Maybe you mixed it up with %P, which shows a *lowercase* version, but isn't Mac OS-compatible... (I would have used that instead, otherwise. Heck...)
Hmm. The point I was getting at is that I didn't realise there was a %P for lowercase, and that I assumed %p was the only one out there, so that if it were found and we wanted to use lowercase, we'd have to manually replace - as was originally done by SMF...
 1. It won't be faster, and it probably will use more memory, though.
 2. I once wrote a 'slash through banned members' mod, which naturally means extending the places where a user's name is used to pull is_activated, plus obviously changing the displayed name. I recall there being 20+ changes I had to make to PersonalMessage to achieve this.
5848
Plugins / Re: Plugin servers / getting plugins to a system
« on October 17th, 2011, 11:58 PM »
OK, so I've thought about this a bit more, after taking some time to review fetch_web_data a little bit, since that's quite a neat little function.[1]

I can't quite make up my mind whether to use HTTP headers as part of the request (and make it a GET) or put the contents in a POST body, either should be doable, though I guess using a GET is more semantically accurate.[2]

In other news I'm thinking of expanding fetch_web_data to support getting an arbitrary number of bytes at the start of a file and making it use the Range headers. The reason? Oversized, non attached images. When someone posts using those, the URL is fetched, the entire image is loaded into memory and its size established with the GD image info functions... but that means downloading the entire image. For the purposes of getting its size, getting the first 1.5K should be sufficient and we can do it ourselves from the file headers.
 1. I mean, in an ideal world, it would be using cURL and no hosts would be putting stupid restrictions in that necessitate such measures, but in a cURL-less, stupid-host-filled world, it's pretty neat.
 2. Especially as GET methods are supposed to be idempotent.
5849
Off-topic / Re: The larger topic on your forum...
« on October 17th, 2011, 10:29 PM »
Public forum... about 400 posts in the largest thread.
Testing... 100,000 posts in a single thread.
5850
Plugins / Re: Plugin servers / getting plugins to a system
« on October 17th, 2011, 10:10 PM »
Quote
Upload zip -> Wedge server receives zip -> Wedge server repackages it as tgz -> Wedge server serves tgz when sending data across servers, and serves zip on request (manual download.)
Yup, that way we'd be providing tgz across the board. Though I don't see a need to offer both, just do one.
Quote
Isn't that what xhr is all about
On the browser side, yes, but I was thinking about doing it on the server instead, to avoid having to cope with cross-domain requests where it won't be sending everything in the URL...