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.
7351
Plugins / Re: Plugin servers / getting plugins to a system
« on October 19th, 2011, 03:42 PM »
I'll trust you on this :P
And yeah, keep-alive is pointing if we're only downloading one file... AFAIK, the only point is to allow for more simultaneous downloads off a single server by reusing earlier connections.
Oh, and can you look into reusing weget for AeMe as well...?
And yeah, keep-alive is pointing if we're only downloading one file... AFAIK, the only point is to allow for more simultaneous downloads off a single server by reusing earlier connections.
Oh, and can you look into reusing weget for AeMe as well...?
7352
Plugins / Re: Plugin servers / getting plugins to a system
« on October 19th, 2011, 11:45 AM »
I see what you mean... Well, considering the function isn't used an awful lot, both versions are fine by me, so use whatever you want ;)
(As for the object name, 'weget' would make a bit more sense. Class-WebGet for the filename is fine.)
(As for the object name, 'weget' would make a bit more sense. Class-WebGet for the filename is fine.)
7353
Plugins / Re: Plugin servers / getting plugins to a system
« on October 19th, 2011, 11:25 AM »
Why 3 lines..?
7354
Features / Re: New revs
« on October 19th, 2011, 10:55 AM »
rev 1121
(16 files, 21kb)
* Updated mini-logos with the current stuff. (images/minilogo*.png)
* Allow show_group_key to show post-based groups instead of just regular groups. The reason? If you're setting a special color for high-level posters, wouldn't you want people to be able to browse them...? (Subs-Membergroups.php)
- Removed $txt['or'], which was only used when OpenID was enabled. I guess I'm good at spotting this kind of crap. Plus, we want to avoid generic word translations as much as possible. I never knew the generic Japanese word for that, come to think of it. Is that または? Hey, SVN supports complex languages, that's cool. Oh yeah, the changelog. (index.language.php)
* Renamed $txt['all'] to $txt['all_pages'], to prevent plugins from reusing it for other purposes. See, in French, 'all' is either 'tout', 'tous' or 'toutes', depending on the context. How are we supposed to act when the plugin provides no context? (index.language.php, Display.php, MessageIndex.php, Unread.php, UnreadReplies.php)
* Renamed $txt['unread_topics_all'] to $txt['unread_topics'], because we no longer have the alternative anyway. Also updated URLs to remove ';all' from them and related logic. (index.language.php, Unread.php, UnreadReplies.php, Recent.template.php)
- 'group_index' is a non-existent block... Good work, eh. (Groups.php)
- $footer_bg is used in Warm, not Wine. (index.css, Warm/index.css)
* Had some weird, dangerous fun with Warm... Okay, okay, I'm letting it go now. (Warm/index.css)
* Reordered field lists in loadMemberData's giant queries. Because it looks cooler. (Load.php)
* Info center needs more breathing space in Welcome. I think. (Welcome.template.php)
* Spacinazi. (ManageMembergroups.template.php)
(16 files, 21kb)
* Updated mini-logos with the current stuff. (images/minilogo*.png)
* Allow show_group_key to show post-based groups instead of just regular groups. The reason? If you're setting a special color for high-level posters, wouldn't you want people to be able to browse them...? (Subs-Membergroups.php)
- Removed $txt['or'], which was only used when OpenID was enabled. I guess I'm good at spotting this kind of crap. Plus, we want to avoid generic word translations as much as possible. I never knew the generic Japanese word for that, come to think of it. Is that または? Hey, SVN supports complex languages, that's cool. Oh yeah, the changelog. (index.language.php)
* Renamed $txt['all'] to $txt['all_pages'], to prevent plugins from reusing it for other purposes. See, in French, 'all' is either 'tout', 'tous' or 'toutes', depending on the context. How are we supposed to act when the plugin provides no context? (index.language.php, Display.php, MessageIndex.php, Unread.php, UnreadReplies.php)
* Renamed $txt['unread_topics_all'] to $txt['unread_topics'], because we no longer have the alternative anyway. Also updated URLs to remove ';all' from them and related logic. (index.language.php, Unread.php, UnreadReplies.php, Recent.template.php)
- 'group_index' is a non-existent block... Good work, eh. (Groups.php)
- $footer_bg is used in Warm, not Wine. (index.css, Warm/index.css)
* Had some weird, dangerous fun with Warm... Okay, okay, I'm letting it go now. (Warm/index.css)
* Reordered field lists in loadMemberData's giant queries. Because it looks cooler. (Load.php)
* Info center needs more breathing space in Welcome. I think. (Welcome.template.php)
* Spacinazi. (ManageMembergroups.template.php)
7355
Plugins / Re: Plugin servers / getting plugins to a system
« on October 19th, 2011, 10:26 AM »
Re: cUrl, here's a 3-year-old post by yours truly about it :P
http://www.simplemachines.org/community/index.php?topic=282969.msg1858080#msg1858080
Latest mod version: http://custom.simplemachines.org/mods/index.php?mod=1569
Use GET if you feel like it's better. You know you want it :P
Range header support in fwd would be cool. aeva_getMedia() already supports it and that's pretty cool :) I thought SMF had it in the first place... My mistake.
http://www.simplemachines.org/community/index.php?topic=282969.msg1858080#msg1858080
Latest mod version: http://custom.simplemachines.org/mods/index.php?mod=1569
Use GET if you feel like it's better. You know you want it :P
Range header support in fwd would be cool. aeva_getMedia() already supports it and that's pretty cool :) I thought SMF had it in the first place... My mistake.
7356
Features / Moving options out of Current Theme
« on October 19th, 2011, 10:15 AM »
(split from New Rev comments)
Found the origin of the bug. Comment out the $current_action = 'moderate' line in Subs.php and it doesn't generate the error anymore... I think it's related to how I moved the moderation center to within the admin menu. Didn't look any further.
I'm seeing FOUS effects in the admin area when dealing with the error log... Hadn't seen these in a while. Dunno if it's due to some bug in the new Opera. Can you tell me if you've seen any of these in Chrome?Quote from Arantor on October 19th, 2011, 03:17 AM There are plenty of options that should be in general options...
Fading delay between items for the news fader: NEWS area
Number of recent posts to display on board index: possibly elsewhere. That's in the info center right..? See below.
Show statistics on board index: --> I don't believe themes would modify the info center so much that this would kill layout...
Show latest member on board index: ditto (might be removed entirely)
Show group key on board index: ditto (should be removed as an option, and always shown.)
"Show who is viewing" --> this is an important feature, it should be enabled by default at the very least... (And the English description is confusing, too.)
Show last modification date on modified posts: if themes don't provide a field for that, then it just won't be shown... Otherwise, they'll provide for it, and make sure it's usable. This is definitely an option for POST settings.
Show view profile button under post: POST settings.
Show user avatars in message view: POST settings or AVATAR settings.
Show personal text in message view: POST settings.
Show gender images in message view: POST settings.
Hide post group titles for grouped members: POST settings or MEMBERGROUP settings.
Enable collapsible additional post options: general, post settings or something...
My conclusion: theme settings should only *contain settings that related to the theme itself (e.g. something like, "show the info center in the sidebar/main area"), not settings related to features that are built into Wedge* (e.g. personal_text has a field in the members table, so all themes are expected to be able to deal with it.)
What do you think...? As an added bonus, we get to have the options made searchable... This is all because yesterday I wasted 5 minutes trying to enable 'show group key' and the admin search refused to point me to it...
We should also rename 'Current Theme' to 'Current theme settings & options' or something. Yeah, I know, it's a bit too long...Quote (It's interesting that Opera is telling me 'unobvious' is not a valid word... I always thought it was. A dictionary gives me these antonyms for obvious: ambiguous, indefinite, obscure, unclear, vague. Hmm, that's very close to what we'd use in French -- ambigu, indéfini, obscur, flou/pas clair, vague.)
If they're actual theme settings, I understand they need to be together in one place, but if they're not logically theme settings per se, they should be elsewhere. At worst, we could add 'aliases/shortcuts' to the correct setting pages in a main page if needed.Quote It's inside the info center... Especially now that InfoCenter is its own template, I don't see how/why themes should delete the option. Additionally -- it's up to the theme to decide what to do. For instance, if I had an admin setting to choose the default sidebar position (left/right), I'd expect the theme to either follow it, or just don't show a sidebar on the left or right (e.g. show it at the bottom). It's a bad example but I hope you get my point...Quote I don't know... :-/
I suppose you're right in that sense. Like, people might want to sort membergroups by color brightness... :lol:Quote I hope you used a walkthrough for that :P It's easier to get below 3 hours that way.
Don't have Steam though... I only have MI2 on my iPod and I don't think it has achievement lists :P Arrr... How appropriate anyway, I play like a cow!Quote Yeah, pretty much... Over 60 times. And the cache would be updated even if 'id_group/additional_groups' isn't updated, which isn't too great IMNSHO.Quote Sure. Do you want me to get started on it maybe...? Or would you rather do it? It's not exciting work :P
Heck, technically I thought you were planning to have a minified version of the file... (Maybe we could move Class-SFTP.php to the wip folder, and include the minified version in Sources. No one has to know about the problems it had :P)Quote Sure, but I'd rather know why SMF/Wedge is using \n when it could be using br in most places :PQuote I'd rather not have ';xml' on any URL that is likely to be reused by someone, reposted on a forum, etc. We can just add a special || action == 'feed' anyway ;)
Found the origin of the bug. Comment out the $current_action = 'moderate' line in Subs.php and it doesn't generate the error anymore... I think it's related to how I moved the moderation center to within the admin menu. Didn't look any further.
Posted: October 19th, 2011, 09:43 AM
I'm seeing FOUS effects in the admin area when dealing with the error log... Hadn't seen these in a while. Dunno if it's due to some bug in the new Opera. Can you tell me if you've seen any of these in Chrome?
It's to make it easier for themes to add options, that are under admin control. There's no way for themes to add user options AFAIK without replacing some/all of the profile template.
Fading delay between items for the news fader: NEWS area
Number of recent posts to display on board index: possibly elsewhere. That's in the info center right..? See below.
Show statistics on board index: --> I don't believe themes would modify the info center so much that this would kill layout...
Show latest member on board index: ditto (might be removed entirely)
Show group key on board index: ditto (should be removed as an option, and always shown.)
"Show who is viewing" --> this is an important feature, it should be enabled by default at the very least... (And the English description is confusing, too.)
Show last modification date on modified posts: if themes don't provide a field for that, then it just won't be shown... Otherwise, they'll provide for it, and make sure it's usable. This is definitely an option for POST settings.
Show view profile button under post: POST settings.
Show user avatars in message view: POST settings or AVATAR settings.
Show personal text in message view: POST settings.
Show gender images in message view: POST settings.
Hide post group titles for grouped members: POST settings or MEMBERGROUP settings.
Enable collapsible additional post options: general, post settings or something...
My conclusion: theme settings should only *contain settings that related to the theme itself (e.g. something like, "show the info center in the sidebar/main area"), not settings related to features that are built into Wedge* (e.g. personal_text has a field in the members table, so all themes are expected to be able to deal with it.)
What do you think...? As an added bonus, we get to have the options made searchable... This is all because yesterday I wasted 5 minutes trying to enable 'show group key' and the admin search refused to point me to it...
We should also rename 'Current Theme' to 'Current theme settings & options' or something. Yeah, I know, it's a bit too long...
Admin > Current Theme makes some modicum of sense, but not a lot - though it's a world better than how unobvious theme settings are to find normally.
If they're actual theme settings, I understand they need to be together in one place, but if they're not logically theme settings per se, they should be elsewhere. At worst, we could add 'aliases/shortcuts' to the correct setting pages in a main page if needed.
It's a theme option because not all themes provide it.
Seriously tempted to move that back out into being a plugin anyway because partly not all themes provide it and partly because so many people want it 'ordered how they want, not just alphabetic', and I think it would be a stretch too far to make core with that in mind. It's not like it's tough to expand any more or anything.
I suppose you're right in that sense. Like, people might want to sort membergroups by color brightness... :lol:
Nice. I spent the rest of my evening trying to score the one remaining achievement I had for Monkey Island II on Steam (complete the game in under 3 hours, just finished with 30 mins to spare), so I haven't looked at the commit yet.
Don't have Steam though... I only have MI2 on my iPod and I don't think it has achievement lists :P Arrr... How appropriate anyway, I play like a cow!
Is there really a lot of places that call updateMemberData?Quote Uncaching on updateMemberData() means doing it on many, many user actions... Might as well not cache anything
I'll update it if it becomes necessary but given how there haven't been updates for a while and it's one of those things that generally 'just works', it should be OK to fix up now.
Heck, technically I thought you were planning to have a minified version of the file... (Maybe we could move Class-SFTP.php to the wip folder, and include the minified version in Sources. No one has to know about the problems it had :P)
Hmm, we should probably test that. It's likely I'm worrying about nothing but I'd rather that and be proven wrong than to be bitten by it later.
Testing for $_GET['xml'] is good but it doesn't automagically do that for the feeds IIRC. But if we had the feeds set that too (if they don't already), then it's a no-brainer.Quote In that case, hmmm... How do we do that? Just a simple if (isset($_GET['xml'])) will do...?
7357
Off-topic / Re: Modular Autoembed Script in Python
« on October 19th, 2011, 08:34 AM »
I have no idea what it means :lol:
7358
Features / Re: New revs - Public comments
« on October 19th, 2011, 12:46 AM »
I'm looking at Settings.template.php and only one question comes to mind... Why this? I can understand some themes might wanna add options, but... This makes it very hard to actually find them (they're neither accessible from Profile > Look & Layout, not from the regular admin area... You have to go to Admin > Current Theme, which I don't find very intuitive.)
And because they're not in the admin area per se, they're not searchable, even they they DO show up in the admin.
Even things like show_group_key... Why would we need to offer to ability to disable it...? To save space?! Why is it a theme option only? It should be in Admin > Membergroups > Settings...
I've been changing show_group_key btw. Now it will also show postgroups, if they have a custom color. Is this okay with everyone? I couldn't think of any strong reason not to do that.Quote from Arantor on October 18th, 2011, 09:18 PM Which is why I added a default color for the highest post group in Wedge... :)Quote Uncaching on updateMemberData() means doing it on many, many user actions... Might as well not cache anything ;)Quote It only matters if you're not going to update the file in the future.Quote Well, we still have a lot of " in the language files, which we used naturally this year AFAIK. So it's pretty much a mixup...Quote Feel free to delete these on your side, too. For instance it's bed time for me... :P
Oh, there's a bug in the current version btw. It's related to createList() and the creation of the menu... Anyway... Just go to the info center, click one of the membergroups in the group key, and see the errors in the menu. Worked on it for 15 minutes and didn't find anything strange (except for a wetem::load() that can safely go in Groups.php...)Quote In that case, hmmm... How do we do that? Just a simple if (isset($_GET['xml'])) will do...?
And because they're not in the admin area per se, they're not searchable, even they they DO show up in the admin.
Even things like show_group_key... Why would we need to offer to ability to disable it...? To save space?! Why is it a theme option only? It should be in Admin > Membergroups > Settings...
I've been changing show_group_key btw. Now it will also show postgroups, if they have a custom color. Is this okay with everyone? I couldn't think of any strong reason not to do that.
We might not but I know sites that do.
Profile area is the main one, but it's not the only one. Group management (Groups.php) is the other main one for assigned groups. Theory says updateMemberData() should be called.
Class-SFTP's formatting is... special. I thought I'd fixed the worst offenders.
Be very careful with those. There are cases where mismatching goes on - when I created the Birthdays plugin out of the email templates, I made use of a little known quirk of SMF's language editor.
Harmonisation is good :)
Oh, there's a bug in the current version btw. It's related to createList() and the creation of the menu... Anyway... Just go to the info center, click one of the membergroups in the group key, and see the errors in the menu. Worked on it for 15 minutes and didn't find anything strange (except for a wetem::load() that can safely go in Groups.php...)
Well, I'll take a look but we might as well not run that particular process if we're outputting XML, I can't see any case in XML (valid or otherwise) where we'd want the colour to be added.
7359
Features / Re: New revs - Public comments
« on October 18th, 2011, 06:43 PM »I figured we might as well cache the membergroups and their colours generally (including post count groups),
Okay, done... (Half an hour later :P)
I also managed to catch the place where postgroups are updated so I can clear the cache, but I wouldn't mind some help spotting other areas where regular groups are updated.
Also, looked into rev 1118, just a note: there are plenty of multiple spaces (not tabs) in the file, most notably several distinct lines often find themselves on the same line separated by many spaces... Odd!
And the ManagePlugins template -- you committed an empty function, is this as intended?
Oh, and before I forget... There are dozens (hundreds?) of " in the language files. Shouldn't we remove them...? I don't think they serve a point these days?
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.
Well, I'm a bit lost in the amount of changes I made today so I'll just commit what I have now and you can look into it.
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.
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?
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
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.
And please generally tell me what you think about the overall building of the feature ;)
Actually, Dragooon answered that one, and wesqlQuery provides for it.
7360
Features / Re: New revs
« on October 18th, 2011, 06:34 PM »
rev 1120
(11 files, 19kb)
+ Wedge will now happily use the membergroup's color when showing profile links -- all the time, instead of just in the Who's Online list and info center. (Subs-Template.php, Subs.php, ManageMembers.language.php)
* Changed default admin and global moderator membergroup colors to something neater that doesn't jump at you. Added a default color for the Hero group (i.e. members with over 500 posts.) (other/install.sql)
- Removed group color retrieval queries from Who's Online and Info Center, since this is being handled elsewhere now. (Subs-MembersOnline.php, Who.php, Who.template.php)
- Removed ability to sort online members by group color... Did anyone actually know this was possible? And what was the point, considering sorting by group name is also possible? (Subs-MembersOnline.php)
- SSI's ssi_recentTopics() never made use of membergroup colors either. (SSI.php)
* I like #c06002 as a color, but h4 (poster name in display template) will now be a virgin when it comes to default color. (sections.css)
+ Profile pages will now show the group/post-group color on the user name, even though it's not technically a profile link. (Profile.template.php)
(11 files, 19kb)
+ Wedge will now happily use the membergroup's color when showing profile links -- all the time, instead of just in the Who's Online list and info center. (Subs-Template.php, Subs.php, ManageMembers.language.php)
* Changed default admin and global moderator membergroup colors to something neater that doesn't jump at you. Added a default color for the Hero group (i.e. members with over 500 posts.) (other/install.sql)
- Removed group color retrieval queries from Who's Online and Info Center, since this is being handled elsewhere now. (Subs-MembersOnline.php, Who.php, Who.template.php)
- Removed ability to sort online members by group color... Did anyone actually know this was possible? And what was the point, considering sorting by group name is also possible? (Subs-MembersOnline.php)
- SSI's ssi_recentTopics() never made use of membergroup colors either. (SSI.php)
* I like #c06002 as a color, but h4 (poster name in display template) will now be a virgin when it comes to default color. (sections.css)
+ Profile pages will now show the group/post-group color on the user name, even though it's not technically a profile link. (Profile.template.php)
7361
Features / Re: New revs
« on October 18th, 2011, 05:57 PM »
rev 1119
(7 files, 8kb)
* Microsecond optimization. I'm only doing this because it's in the cache code, and the cache is all about speed... (Subs-Cache.php)
* String concatenation optimization. As if. (Display.template.php)
* Typos. (ManagePlugins.english.php, ManagePlugins.php)
* Translation. (ManagePlugins.french.php)
! The two new files were missing the closing '?>'. I know it's not that bad, but if we should do it for one, we should do it for all of them ;) (Class-FileWritable.php, Class-SFTP.php)
(7 files, 8kb)
* Microsecond optimization. I'm only doing this because it's in the cache code, and the cache is all about speed... (Subs-Cache.php)
* String concatenation optimization. As if. (Display.template.php)
* Typos. (ManagePlugins.english.php, ManagePlugins.php)
* Translation. (ManagePlugins.french.php)
! The two new files were missing the closing '?>'. I know it's not that bad, but if we should do it for one, we should do it for all of them ;) (Class-FileWritable.php, Class-SFTP.php)
7362
Plugins / Re: Personal plugin showcase (yes, I'm an attention grabbing git)
« on October 18th, 2011, 05:17 PM »
Some hooks are stored in an array but I doubt any of these would never be called the normal way elsewhere?
7363
The Pub / [Archive] Re: Logo Madness
« on October 18th, 2011, 03:48 PM »
- Oh... Sorry then ;)
- oh it's no biggie, I'm used to that, and it's only for uploading logos that I need to access the root...
- oh it's no biggie, I'm used to that, and it's only for uploading logos that I need to access the root...
7364
The Pub / [Archive] Re: Logo Madness
« on October 18th, 2011, 03:12 PM »
The sidebar logo is wedgelevelf, not wedgelogof ;)
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 ;)
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 ;)
7365
Plugins / Re: Personal plugin showcase (yes, I'm an attention grabbing git)
« on October 18th, 2011, 03:10 PM »
Maybe you should make a script that runs through your local install and automatically extracts hook names ;)
The problem is that it's not something we can easily overlook. We need a full list of hooks, if only to be able to document them later... (What you did in ManagePlugins was a good start!)
The problem is that it's not something we can easily overlook. We need a full list of hooks, if only to be able to document them later... (What you did in ManagePlugins was a good start!)