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.
Topics - Arantor
61
Off-topic / I dislike FB Connect... and now we have issues with Twitter Connect
« on March 8th, 2013, 10:46 PM »
http://www.theregister.co.uk/2013/03/08/twitter_oauth_leaked_keys/
Slap upside the back of the head for Twitter devs.
Slap upside the back of the head for Twitter devs.
62
Features / Maybe it's the rum talking... (language editing for plugins)
« on March 4th, 2013, 02:43 AM »
...but I just had a wicked idea. And this is like da bomb because it solves an awful lot of headaches very quickly.
For most plugins, they'll have their language files and keep them to themselves like good little plugins. But some plugins are not so well behaved because they'll need to load language files in other contexts. Probably the biggest example is menu items.
Now, I want to have a menu editor function in the core - some day - but the biggest problem is handling language items and doubly so for plugins. How can we have them around and loaded, and still do it efficiently?
And it occurred to me... no, I don't mean reinstating that shitfest Modifications.language.php, that shit can remain dead and buried. No, what I had in mind was far more elegant.
Menu items are needed every page, right? That means, essentially, wherever loadLanguage('index') is called, the menu items are needed. So why not have some facility whereby a plugin's language strings can be injected into the database? Obviously I wouldn't be expecting language files to do their own DB inserts, but I'd probably have a facility in the plugin-info.xml that says to load a given language and append it to an existing set of entries. That way if a plugin wants to add a new menu item, it just has to add its language file correctly, the plugin manager kicks it into the DB, recaches etc. and then it's available without having to load an extra file.
Then the menu editor just becomes some juggling of arrays and cache items, plus any other plugin that wants language strings 'everywhere' can just append them where it needs them if that makes sense.
If it doesn't, just prod me in the morning and I'll see if it still makes sense :D
For most plugins, they'll have their language files and keep them to themselves like good little plugins. But some plugins are not so well behaved because they'll need to load language files in other contexts. Probably the biggest example is menu items.
Now, I want to have a menu editor function in the core - some day - but the biggest problem is handling language items and doubly so for plugins. How can we have them around and loaded, and still do it efficiently?
And it occurred to me... no, I don't mean reinstating that shitfest Modifications.language.php, that shit can remain dead and buried. No, what I had in mind was far more elegant.
Menu items are needed every page, right? That means, essentially, wherever loadLanguage('index') is called, the menu items are needed. So why not have some facility whereby a plugin's language strings can be injected into the database? Obviously I wouldn't be expecting language files to do their own DB inserts, but I'd probably have a facility in the plugin-info.xml that says to load a given language and append it to an existing set of entries. That way if a plugin wants to add a new menu item, it just has to add its language file correctly, the plugin manager kicks it into the DB, recaches etc. and then it's available without having to load an extra file.
Then the menu editor just becomes some juggling of arrays and cache items, plus any other plugin that wants language strings 'everywhere' can just append them where it needs them if that makes sense.
If it doesn't, just prod me in the morning and I'll see if it still makes sense :D
63
Features / Saving Bytes Every Page - Or, How I Learned To Stop Worrying And Enhance Search
« on February 28th, 2013, 09:43 PM »
OK, so I was talking to Asgard yesterday and he commented about how the search redundancy in SMF always annoyed him, hence the haiku-esque thought yesterday.
His complaint is that we have a search form every page, and we have a search button, why do we need both? Either drop the quick search, or drop the menu item, and be done with it.
And I thought about this, and I thought some more. Then I had some tea and all other arguments are invalid :D
OK, here's what I want to do.
1. Drop the search menu entirely, there's no need for it including all its fun markup.
2. Add a link to the full search page from just under the search form. This isn't duplication. This means when you want to do things the quick search can't do, you can still get to it.
3. Drop the distinction between simple and advanced searching and just have it push to the 'advanced' page and be done with it.
The result is simpler, cleaner functionality without multiple places on the page being duplicated.
His complaint is that we have a search form every page, and we have a search button, why do we need both? Either drop the quick search, or drop the menu item, and be done with it.
And I thought about this, and I thought some more. Then I had some tea and all other arguments are invalid :D
OK, here's what I want to do.
1. Drop the search menu entirely, there's no need for it including all its fun markup.
2. Add a link to the full search page from just under the search form. This isn't duplication. This means when you want to do things the quick search can't do, you can still get to it.
3. Drop the distinction between simple and advanced searching and just have it push to the 'advanced' page and be done with it.
The result is simpler, cleaner functionality without multiple places on the page being duplicated.
64
Off-topic / Crashing PHP in one easy lesson (aka WTF?)
« on February 24th, 2013, 04:07 PM »
So I'm working on the language editor, and moved its templates into its own handy dandy file, ManageLanguages.template.php. And as such I'm removing the old code I don't want.
But if I remove this one div from it, see before/after shots, so you can see what was removed - just removing that div on line 319 will not generate a 500, it will simply force PHP to abort entirely with just this in the Apache error log:
Code: [Select]
I have no idea WTF is going on.
But if I remove this one div from it, see before/after shots, so you can see what was removed - just removing that div on line 319 will not generate a 500, it will simply force PHP to abort entirely with just this in the Apache error log:
[Sun Feb 24 15:03:23 2013] [notice] Parent: child process exited with status 255 -- Restarting.I have no idea WTF is going on.
65
Features / Message icons, some proposed changes
« on February 23rd, 2013, 11:40 PM »
There are a goodly number of things wrong with message icons and I want to get some feedback on them and what to do with them.
1. Single set of icons, not multiple sets
They're actually changeable per physical theme at this point in time. I don't know any theme that ever actually shipped *its own* as such; all the ones I ever saw just shipped whatever the default icons were in SMF at the time.[1] I'd like to propose we make it a single set of icons.
2. Get rid of this 'enable customised icons' nonsense.
There is really no need for this nonsense. There is, yes, the argument to be made about performance, but caching would fix that anyway. We'd get a simpler and better to use UI out of it.
3. Drop the enforcement of it being .gif
There's really no reason why it must be .gif, other than having a standard format to work with. But that's solvable through another thing.
Then we can get a bit more exotic if we wanted.
4. Stop storing it as a textual item.
If we're already storing them in the database anyway, we will already have numeric ids for them. I see no reason why we can't make proper use of them and just store a numeric id in the messages table and be done with it (yes that would SAVE space!)
This isn't without its issues, because it would mean that all the silent-forced changes that occur (for iPod/iPhone/tablets/Android etc. not to mention moved notices, deleted posts at present and posts with attachments) would also have to be in that table. This raises other issues (what happens if the user deletes them? what happens with migrating existing SMF stuff including this site?)
I'm not exactly dead set on this one, but it is certainly an option to explore and not without its caveats. Though it could also mean the user doesn't want those things set, e.g. if they delete the tablet one, don't use that replacement later.
5. Topic filtering
Assuming we make it a numeric id, we could store that numeric id in the topics table (first post's)... it would allow us to stick an index on it and then filter topics on it. Of course, any plugin that adds its own would be rather awkward but it's not insurmountable.
/discuss
1. Single set of icons, not multiple sets
They're actually changeable per physical theme at this point in time. I don't know any theme that ever actually shipped *its own* as such; all the ones I ever saw just shipped whatever the default icons were in SMF at the time.[1] I'd like to propose we make it a single set of icons.
2. Get rid of this 'enable customised icons' nonsense.
There is really no need for this nonsense. There is, yes, the argument to be made about performance, but caching would fix that anyway. We'd get a simpler and better to use UI out of it.
3. Drop the enforcement of it being .gif
There's really no reason why it must be .gif, other than having a standard format to work with. But that's solvable through another thing.
Then we can get a bit more exotic if we wanted.
4. Stop storing it as a textual item.
If we're already storing them in the database anyway, we will already have numeric ids for them. I see no reason why we can't make proper use of them and just store a numeric id in the messages table and be done with it (yes that would SAVE space!)
This isn't without its issues, because it would mean that all the silent-forced changes that occur (for iPod/iPhone/tablets/Android etc. not to mention moved notices, deleted posts at present and posts with attachments) would also have to be in that table. This raises other issues (what happens if the user deletes them? what happens with migrating existing SMF stuff including this site?)
I'm not exactly dead set on this one, but it is certainly an option to explore and not without its caveats. Though it could also mean the user doesn't want those things set, e.g. if they delete the tablet one, don't use that replacement later.
5. Topic filtering
Assuming we make it a numeric id, we could store that numeric id in the topics table (first post's)... it would allow us to stick an index on it and then filter topics on it. Of course, any plugin that adds its own would be rather awkward but it's not insurmountable.
/discuss
| 1. | This is most notable in the Bloc themes where they were upgraded from 1.1.x to 2.0 themes but kept the 1.1.x message icons. |
66
Plugins / SVN Prettifier
« on February 23rd, 2013, 08:09 PM »
So I had some long-running batch processes to keep an eye on and while I did that, I quickly knocked this together. It's using the LED Icon Set because I already had icons handy for them (as I used much the same icons for SimpleDesk announcements and thus could easily grab them)
So yeah, 20 minutes or so later (and batch process still running), and I have this. The idea is that you feed it a topic or topics that are SVN changelogs and it'll pretty them up a little, just changing the first character into an image. It's dull, but it amused me for 20 minutes while otherwise bored but not really able to do *that* much.
Not the usual admin refinements, sorry :P Couldn't even be arsed uploading it to the SVN repo or to the plugins folder, it's really tiny and not like I couldn't just quickly make it again in future.
So yeah, 20 minutes or so later (and batch process still running), and I have this. The idea is that you feed it a topic or topics that are SVN changelogs and it'll pretty them up a little, just changing the first character into an image. It's dull, but it amused me for 20 minutes while otherwise bored but not really able to do *that* much.
Not the usual admin refinements, sorry :P Couldn't even be arsed uploading it to the SVN repo or to the plugins folder, it's really tiny and not like I couldn't just quickly make it again in future.
67
Off-topic / System visitations: vB 3.8.7
« on February 23rd, 2013, 05:48 AM »
So, some of you know that I own licences for different systems. I consider it a valid research expense and I don't mind shelling out to do proper research for what I really care about. I have current licences for XenForo, IPB and yesterday I picked up a vB licence which means I have an active installation of vB 3, vB 4 and vB 5 to play with. I will get round to the others in time, but vB 3 is what I'm looking at right now.
I'm not going to post screenshots, but I'm going to share my reactions and thoughts to these things as I find them. It may be interesting to someone, it may not, I don't know. All of this is on localhost and I don't really care about performance at this stage. I'm not even going to really touch on the user end so much, because from a user aspect they all seem to be mostly consistent. But if I get time I'll look at it.
Admin Panel
This is the first time I've seen the vB admin panel. Having seen a 3.6 or 3.7 moderation panel, the use of frames doesn't surprise me. Yes, ACTUAL FRAMES. Not even iframes.
My first reaction, though, is fuck, it's ugly. I don't even want to call it utilitarian, because while it is functional, it is ugly. I like beauty in my toys.
There are some interesting things to this though - we have a side menu with a shit-ton of first level options: vBulletin Options, Styles & Templates, Langages & Phrases, FAQ, Notices, Announcements, Forums & Moderators, Calendars, Threads & Posts, Thread Prefixes, Moderation, Attachments, Users, Usergroups, Social Groups, User Infractions, User Profile Fields, User Ranks, User Reputations, User Albums, User Titles, Paid Subscriptions, Avatars, Post Icons, Smilies, Custom BB Codes, RSS Feeds, Scheduled Tasks, Plugins & Products, Statistics & Logs, Maintenance.
Monkey butts, that's a lot of stuff. It intrigues me on a number of levels. Firstly... it does mean that everything most people would want is available out of the box, and presumably maintained up to the same standard as the core. Once you get the core dev out of the way, maintenance should be relatively easy.
I gotta say it does make me pause to reflect on what I want to see as a core feature versus what should be a plugin and I just know that's going to cause trouble, especially if I intend to monetise any of them.
Let's kick off. vBulletin Options has... vBulletin Options as the first menu item, which takes me to a page where I can select from about 40 areas, ranging from 'Turn Your vBulletin On and Off', 'Site Name / URL / Contact Details', through Date and Time Options, Email Options, Social Group Options and so on. In other words, collating all the very generic options pages in one place. Interesting tactic. I don't like it, but it's interesting.[1]
Anyway, lots and lots of pages of settings. Most of them seem fairly straightforward and most of them have mostly similar analogues to SMF and Wedge - if you've cruised through the admin panel and seen any of the generic pages you will have seen this, mostly. Though I will note that their UI is arranged to scroll downwards a lot and have concentrated pages with lots of stuff in, as opposed to more but shorter pages. I'm not intrinsically opposed to lots and lots of options, but there are definitely cases of 'less is more' and anyone who knows me will know I like keeping related functionality together.
Interesting to see that 'Social Bookmarking' is still a feature - back in the days before we had Facebook and Twitter and G+ everywhere, we had Digg, del.icio.us, StumbleUpon and Google's social bookmarking feature. You can't even make this stuff up. (And yes, vB has it built in, but with built in support for it. This intrigues me, actually. I don't want it in the core but I can see people think it should be.)
Ah, the Style Manager, I've been curious about this for a while. Editing templates in the DB, they said. Safer than using real code, they said.
But DAMN.
Code: [Select]
Code: [Select]
Just... eew. Seriously, I get the idea of a template engine, be that Smarty or TOX-G or whatever. I understand the logic and have in the past recommended it in certain circumstances. But this hellspawn bastardisation of HTML, meta HTML and PHP in line? What the Serious FUCK is this?
The ability to configure basic CSS variables with a *nice* interface (and this is easily the nicest UI I've seen yet in vB 3, though I gotta say, it's not a complete trainwreck) is interesting. I have attached a screenshot. I'm not saying I want it in the core, because I don't, but it is fundamentally an interesting concept.
Then we have the language editor. Given current stuff, this intrigues me too, to see what they've done with it, knowing full well what I'd probably find. The amount of configuration is surprising even for me, especially as I plan to remove most of the configurability of 'key' items out of the language editor. It strikes me as something that is surprisingly low use. The actual language editor part itself is completely as expected, with some nice quirks around searching for languages. The quirk primarily that comes to mind is 'overkill'.
FAQ... oh, this is nice, a built in FAQ editor. What's more interesting is that this is the one way I'd be encouraged to re-add the help tab: by making it entirely configurable. You create items which can have child items again and again, it's all very straightforward really. As many levels as you want, as many siblings in a given level. Then we have the UI. I have seen this in XF and there it looked incongruous. Here... it's oddly in character but still unnecessary.
Every item has a 'display order'. Yup, you put in a number to indicate what position these things should be in. Now, I get that. Internally, that's exactly how it works. You have a number and it indicates position. Except there's no need to show the *user* that. Back in the early 2000s, maybe, but it's definitely a relic of back then. (Note, SMF never showed big ol' lists of display numbers to people even back then.) Everything else is straightforward enough there, though the fact it's showing me the unprocessed code is slightly disturbing (yay for more yucky mashup languages!) but I'll let it slide. It's workable if ugly.
Notices... now this is a feature I haven't seen before, or if I have I haven't made a mental note of it (though I believe XF has something similar, I just never dug in enough). A Notice, essentially, is a block of code shown at the top of the page based on matching conditions, e.g. show a given block if the user is/isn't a given group, is in a given board/its sub-boards, using a given style, user has not visited lately, user has between x and y posts, user has no posts, user has given amount of reputation, infractions, PM storage, username... the list goes on. Pretty much anything you can conveniently imagine would cover it, I think.
Now this is an interesting concept for me. It means you could put ads in it if you so desired, sure, but you could also do so much more with it. One admin I know uses this to handle birthday wishes to his users (since there's a notice for when it's their birthday), to the point where I'd probably want to put it in the core rather than rely on it being a plugin, even if I wrote it. It's sufficiently useful, I think, that it could justify itself.
Announcements - a similar idea but intended to be shortlived rather than general notices. The idea is that you get what amounts to a posting box, a start and an end date and some minor formatting options and get to display notices like that. It's an interesting idea for quick notifications that have higher prominence than pinned topics and that will automatically fade away later on - and don't allow for comments.
Then we get to the Forum Manager - remember, vB calls them forums not boards. Yay for Display Order number boxes. This is intriguing... we have some of the typical stuff - title, description, redirection, default sort order[2] and there's some stuff I wouldn't have thought of.
You can add a list of email addresses to notify when there's a new post or topic in that board. You can also, from main board configuration, turn on post/thread/attachment moderation right there. Interesting. I won't be changing our moderation filters any time soon but it is interesting.
Interesting what other things are set - you can disable bbcode/smileys/img bbc/post icons etc all by board. I find this fascinating that you have this much control - and mostly unnecessary. I have yet to encounter a situation where I'd want one board to have these and not another.
Permissions, ah how we love thee. Wait... you can remove admins' permissions in a board? Seriously? (Actually, that's an interesting concept. I know cases where users have asked about it for specific and unusual reasons.)
Other than that the approach seems to be reasonably sane - set defaults per user group then let them either use the default or set by board. Hell to manage on larger configurations with many boards of course (which is why SMF went to board profiles in the first place).
Calendar... not really a great amount to say, looks like much the same as I'd envisaged our calendar becoming really.
Threads and Posts... lots of loving pruning (first/last post min/max days ago, min/max replies, min/max views, include/ignore pinned topics, include/ignore unapproved/deleted/locked/redirect) or even base it on who made the topic, what the topic's title is, what board(s) in question... it's very thorough, but like other things perhaps too thorough. I get the feeling it's a bit like they put everything they could think of in, good idea or not. There's also move topics between boards, same criteria. Plus you can... remove the poll on a topic if you know it's id? Then we have who voted what, and interestingly enough to prune edit history. Edit history is a core feature, interesting.
Thread prefixes... interesting idea. I can see the use for this in some contexts and some kinds of sites, not sure I'd want it as a core feature but for those who would use it, it is often a make or break feature. The features do not surprise me particularly, the only thing that does is the fact is demands people provide both plain text (for old fashioned dropdowns) and rich text displays.
Bah, soon be time for bed and so much more to explore. More when I've been to bed.
I'm not going to post screenshots, but I'm going to share my reactions and thoughts to these things as I find them. It may be interesting to someone, it may not, I don't know. All of this is on localhost and I don't really care about performance at this stage. I'm not even going to really touch on the user end so much, because from a user aspect they all seem to be mostly consistent. But if I get time I'll look at it.
Admin Panel
This is the first time I've seen the vB admin panel. Having seen a 3.6 or 3.7 moderation panel, the use of frames doesn't surprise me. Yes, ACTUAL FRAMES. Not even iframes.
My first reaction, though, is fuck, it's ugly. I don't even want to call it utilitarian, because while it is functional, it is ugly. I like beauty in my toys.
There are some interesting things to this though - we have a side menu with a shit-ton of first level options: vBulletin Options, Styles & Templates, Langages & Phrases, FAQ, Notices, Announcements, Forums & Moderators, Calendars, Threads & Posts, Thread Prefixes, Moderation, Attachments, Users, Usergroups, Social Groups, User Infractions, User Profile Fields, User Ranks, User Reputations, User Albums, User Titles, Paid Subscriptions, Avatars, Post Icons, Smilies, Custom BB Codes, RSS Feeds, Scheduled Tasks, Plugins & Products, Statistics & Logs, Maintenance.
Monkey butts, that's a lot of stuff. It intrigues me on a number of levels. Firstly... it does mean that everything most people would want is available out of the box, and presumably maintained up to the same standard as the core. Once you get the core dev out of the way, maintenance should be relatively easy.
I gotta say it does make me pause to reflect on what I want to see as a core feature versus what should be a plugin and I just know that's going to cause trouble, especially if I intend to monetise any of them.
Let's kick off. vBulletin Options has... vBulletin Options as the first menu item, which takes me to a page where I can select from about 40 areas, ranging from 'Turn Your vBulletin On and Off', 'Site Name / URL / Contact Details', through Date and Time Options, Email Options, Social Group Options and so on. In other words, collating all the very generic options pages in one place. Interesting tactic. I don't like it, but it's interesting.[1]
Anyway, lots and lots of pages of settings. Most of them seem fairly straightforward and most of them have mostly similar analogues to SMF and Wedge - if you've cruised through the admin panel and seen any of the generic pages you will have seen this, mostly. Though I will note that their UI is arranged to scroll downwards a lot and have concentrated pages with lots of stuff in, as opposed to more but shorter pages. I'm not intrinsically opposed to lots and lots of options, but there are definitely cases of 'less is more' and anyone who knows me will know I like keeping related functionality together.
Interesting to see that 'Social Bookmarking' is still a feature - back in the days before we had Facebook and Twitter and G+ everywhere, we had Digg, del.icio.us, StumbleUpon and Google's social bookmarking feature. You can't even make this stuff up. (And yes, vB has it built in, but with built in support for it. This intrigues me, actually. I don't want it in the core but I can see people think it should be.)
Ah, the Style Manager, I've been curious about this for a while. Editing templates in the DB, they said. Safer than using real code, they said.
But DAMN.
$template_hook[postbit_start]
<table class="tborder" id="post$post[postid]" cellpadding="$stylevar[cellpadding]" cellspacing="$stylevar[cellspacing]" border="0" width="100%" align="center"> <div id="postmenu_$post[postid]">
<if condition="$show['profile']">
<a class="bigusername" href="member.php?$session[sessionurl]u=$post[userid]">$post[musername]</a>
$post[onlinestatus]
<script type="text/javascript"> vbmenu_register("postmenu_$post[postid]", true); </script>
<else />
$post[musername]
</if>
</div>Just... eew. Seriously, I get the idea of a template engine, be that Smarty or TOX-G or whatever. I understand the logic and have in the past recommended it in certain circumstances. But this hellspawn bastardisation of HTML, meta HTML and PHP in line? What the Serious FUCK is this?
The ability to configure basic CSS variables with a *nice* interface (and this is easily the nicest UI I've seen yet in vB 3, though I gotta say, it's not a complete trainwreck) is interesting. I have attached a screenshot. I'm not saying I want it in the core, because I don't, but it is fundamentally an interesting concept.
Then we have the language editor. Given current stuff, this intrigues me too, to see what they've done with it, knowing full well what I'd probably find. The amount of configuration is surprising even for me, especially as I plan to remove most of the configurability of 'key' items out of the language editor. It strikes me as something that is surprisingly low use. The actual language editor part itself is completely as expected, with some nice quirks around searching for languages. The quirk primarily that comes to mind is 'overkill'.
FAQ... oh, this is nice, a built in FAQ editor. What's more interesting is that this is the one way I'd be encouraged to re-add the help tab: by making it entirely configurable. You create items which can have child items again and again, it's all very straightforward really. As many levels as you want, as many siblings in a given level. Then we have the UI. I have seen this in XF and there it looked incongruous. Here... it's oddly in character but still unnecessary.
Every item has a 'display order'. Yup, you put in a number to indicate what position these things should be in. Now, I get that. Internally, that's exactly how it works. You have a number and it indicates position. Except there's no need to show the *user* that. Back in the early 2000s, maybe, but it's definitely a relic of back then. (Note, SMF never showed big ol' lists of display numbers to people even back then.) Everything else is straightforward enough there, though the fact it's showing me the unprocessed code is slightly disturbing (yay for more yucky mashup languages!) but I'll let it slide. It's workable if ugly.
Notices... now this is a feature I haven't seen before, or if I have I haven't made a mental note of it (though I believe XF has something similar, I just never dug in enough). A Notice, essentially, is a block of code shown at the top of the page based on matching conditions, e.g. show a given block if the user is/isn't a given group, is in a given board/its sub-boards, using a given style, user has not visited lately, user has between x and y posts, user has no posts, user has given amount of reputation, infractions, PM storage, username... the list goes on. Pretty much anything you can conveniently imagine would cover it, I think.
Now this is an interesting concept for me. It means you could put ads in it if you so desired, sure, but you could also do so much more with it. One admin I know uses this to handle birthday wishes to his users (since there's a notice for when it's their birthday), to the point where I'd probably want to put it in the core rather than rely on it being a plugin, even if I wrote it. It's sufficiently useful, I think, that it could justify itself.
Announcements - a similar idea but intended to be shortlived rather than general notices. The idea is that you get what amounts to a posting box, a start and an end date and some minor formatting options and get to display notices like that. It's an interesting idea for quick notifications that have higher prominence than pinned topics and that will automatically fade away later on - and don't allow for comments.
Then we get to the Forum Manager - remember, vB calls them forums not boards. Yay for Display Order number boxes. This is intriguing... we have some of the typical stuff - title, description, redirection, default sort order[2] and there's some stuff I wouldn't have thought of.
You can add a list of email addresses to notify when there's a new post or topic in that board. You can also, from main board configuration, turn on post/thread/attachment moderation right there. Interesting. I won't be changing our moderation filters any time soon but it is interesting.
Interesting what other things are set - you can disable bbcode/smileys/img bbc/post icons etc all by board. I find this fascinating that you have this much control - and mostly unnecessary. I have yet to encounter a situation where I'd want one board to have these and not another.
Permissions, ah how we love thee. Wait... you can remove admins' permissions in a board? Seriously? (Actually, that's an interesting concept. I know cases where users have asked about it for specific and unusual reasons.)
Other than that the approach seems to be reasonably sane - set defaults per user group then let them either use the default or set by board. Hell to manage on larger configurations with many boards of course (which is why SMF went to board profiles in the first place).
Calendar... not really a great amount to say, looks like much the same as I'd envisaged our calendar becoming really.
Threads and Posts... lots of loving pruning (first/last post min/max days ago, min/max replies, min/max views, include/ignore pinned topics, include/ignore unapproved/deleted/locked/redirect) or even base it on who made the topic, what the topic's title is, what board(s) in question... it's very thorough, but like other things perhaps too thorough. I get the feeling it's a bit like they put everything they could think of in, good idea or not. There's also move topics between boards, same criteria. Plus you can... remove the poll on a topic if you know it's id? Then we have who voted what, and interestingly enough to prune edit history. Edit history is a core feature, interesting.
Thread prefixes... interesting idea. I can see the use for this in some contexts and some kinds of sites, not sure I'd want it as a core feature but for those who would use it, it is often a make or break feature. The features do not surprise me particularly, the only thing that does is the fact is demands people provide both plain text (for old fashioned dropdowns) and rich text displays.
Bah, soon be time for bed and so much more to explore. More when I've been to bed.
| 1. | I don't want to derail myself but a very vivid thought here is the similarity to how XenForo arranges itself much the same, and I suspect Kier was largely responsible. |
| 2. | Did I actually make a UI item for that already? I don't think I did :/ |
68
Archived fixes / Drafts aren't being pruned properly
« on February 23rd, 2013, 04:59 AM »
For some reason drafts aren't returning AJAXively properly. I suspect the change of AJAX vs $_REQUEST['xml'] is to blame (it is there in the post workflow for a reason, but I'm busy, will review it tomorrow)
69
Archived fixes / Language strings not being loaded properly in error log
« on February 22nd, 2013, 07:26 PM »
Observed on this site - but I don't understand why.
This is why there are *hundreds* of errors, each time I go to the error log I generate more errors :/
This is why there are *hundreds* of errors, each time I go to the error log I generate more errors :/
70
Other software / F**k the SMF project. F**k it up its stupid a**. <-- says Arantor ;)
« on February 22nd, 2013, 07:08 PM »
First up, I generally try to avoid profanity, but I'm just not able to figure out a better way to express it, so it is with a title that sums up my feelings in a short, sweet film reference.
I write this as me, a former SMF contributor. not with my 'Wedgeward' hat on.
I shouldn't really dignify the comments that have been made, and simply ignore them with all the contempt they deserve but that is not my way. Being open about things, including my feelings, is pretty damn important to me. It is also ironic that this is one of the failings I will be talking about.
I am aware of the things said in private about me and Norv, about how we want SMF to die and so on.[1]
I find it interesting how they won't say it to our face, they won't level these comments to our faces but they'll say it behind our backs where we can't deal with it.
It's wrong, of course. The comments we've been making aren't trying to kill SMF, we're trying to explain why SMF is doing so well at trying to kill itself. If it's going to survive, it needs to be more open with its community, just as a start. Like a roadmap or even some idea what SMF 2.1 is supposed to be... it's only been 20 months in the making and no-one outside of Github reviewers really knows what's actually in it. There are some vague comments about new features but it's hardly much more than straight up marketing spiel.
For any project that would be fairly poor, but for a project that spent so much time trying to claim it is open, that's truly poor. It is also a major contributing factor.
Here's one thing some people don't seem to understand: Wedge is a closed project. We are, and have always been, hesitant to accept contributions from third parties, we haven't revealed a roadmap or anything... but 1) we've always made it clear that we have the role of benevolent dictators for Wedge and 2) we do actually involve our community in things. I suggest new ideas and features at least once a week specifically for community involvement in shaping those ideas.
Contrast this to SMF: a project that claims to be open, that has an organisation to support project development, with a project team of about two dozen people (which is low, I remember it at times being 40+). On top of that there is a Board of Directors who makes decisions that not even the team are fully made aware of, even as organisation members. (Because that's good, right?) They're not even open amongst themselves, let alone open with the community as a whole.
No plans have been announced for 2.1 development as such, or indeed anything beyond that. Truth of the matter: the lead dev in 2.0 didn't even want 2.1 to exist. I understand that - she wanted SMF to progress on smCore and devote all its time to that. The project had a rumbling and decided that 2.1 was necessary to prevent SMF falling even further behind - with the understanding that smCore + SMF would be at least 2 years away from that point. And so it came into being - in 2011. Except here we are in 2013 and only alphas of a 'small incremental release' have been hinted at, and nothing beyond 2.1 has been even mentioned, as smCore is clearly defunct now. (But again, lack of transparency about all of this.)
I understand that development is slow, I understand that only too well. But why is there no real communication about the roadmap? I'm not asking for chapter and verse, or pointing fingers at people for not doing their job properly. I'm just trying to point out that this organisation is failing to do a key job in onward development. (Our changelog is very public.)
At this point you can turn around and say that we haven't released a roadmap either and that we could be called hypocritical. It'd also be wrong, but you could claim it. The entire thing is one long rolling upgrade at this point in time. We can't tell you exactly what Wedge 1.0 will be, because it's still growing and evolving. Setting arbitrary boundaries at this stage would actually limit what we do. Right now we're still figuring out some of the key things we want to have. But what we do have is very public and we encourage discussion on it.
While we're on the name calling angle, actually, there is a claim from certain members of the project that people like me and Norv have 'more credibility' than the SMF team and 'how evil they must be' and so on.[2] It's all bullshit.
The reason we have more 'credibility' is because we don't do stuff in private much, neither Wedge nor ElkArte.[3] We try to involve everyone where possible. We certainly don't sit in a tower on high making decisions about things, especially things that we aren't going to get involved with making. You don't see a project sitting above Nao and myself telling us what we should be writing.
But more than that, I'm not interested in killing SMF. I never have been. I saw back in 2009 when I first joined the team that it was in trouble. It's still there, despite everything I'd done in the meantime, despite everything Norv did, despite everything that's happened - it's still in trouble. If I genuinely thought SMF was so poor and I wanted it to die, why did I spend a lot of time on support issues? Could it be because somewhere, I still care? Nah, that would controvert this idea that I want SMF to die, and god forbid we should let the truth get in the way of a righteous smiting.
I should also add, I have heard it said that the community shouldn't have been made aware of the drama in the team in the past. Except this to me is a colossal problem. That implies that the team are not part of the community. That they're somehow removed from the community. Now, the team are all heavyweight contributors to the project, I have no beef with that. What I have a problem with is the notion that being long-time contributors somehow makes their opinion more important than the rest of the community's.
Compare and contrast that with Wedge. There are only two people in this project whose opinion outweighs everyone else's. There is also a small group of people whose opinion outranks others. This is not really a secret. But let me explain how it works.
The top two people are Nao and myself. We write the vast bulk of Wedge's code. That gives us final say on what happens. The reason, then, that our opinion is more important is not because we have inflated egos or anything but because we're the ones *actually doing it*.
The second group of people I mention are the Consultants. The reason they have an opinion we pay more attention to is because, again, they're actually doing it. They're looking at the code, they're actively writing code that has been taken under consideration and in some cases even drafted into the core. Again, because they're actually getting down and dirty with the code, we pay them some extra attention.
Then there's everyone else. It is not to say that we don't listen - because we certainly do. We listen to every comment and every thread that gets made. We're not under any prerogative to accept it, just as I'm not under any prerogative to accept any code Nao writes and he, I, vice versa.
Compare this with SMF. They have a vast group of people who are not code authors, who are not getting down into the code suggesting how things could/should/must be done. Why is their opinion more important than the regular users? Should it be so? I'd say not... you can be a major contributor without being a 'team member'. I've proved that. I can happily make thousands of posts without being a team member or without having a badge, and my opinion is considered as valid as a team member's in most cases because it's backed up by experience and/or code. So the badge is not a requirement. It is the worst kind of meritocracy, the self-serving, self-selecting kind.
So with the latest salvo (e.g. Motoko's snide comments, and the comment about the only place I want to see SMF is down the drain), I might as well just leech off sm.org rather than contribute because it's increasingly clear my comments aren't wanted.[4] Since the management is already convinced that I'm desperately trying to kill SMF, I might as well indulge them in that by taking Wedge so far beyond SMF that it'll never catch up. Then it can die a quiet, hopefully painless death because that's the best it can hope for now.
There's the gauntlet, folks, thrown down, right there.
:edit: by Nao: both clarified and concealed topic subject... :eheh:
I write this as me, a former SMF contributor. not with my 'Wedgeward' hat on.
I shouldn't really dignify the comments that have been made, and simply ignore them with all the contempt they deserve but that is not my way. Being open about things, including my feelings, is pretty damn important to me. It is also ironic that this is one of the failings I will be talking about.
I am aware of the things said in private about me and Norv, about how we want SMF to die and so on.[1]
I find it interesting how they won't say it to our face, they won't level these comments to our faces but they'll say it behind our backs where we can't deal with it.
It's wrong, of course. The comments we've been making aren't trying to kill SMF, we're trying to explain why SMF is doing so well at trying to kill itself. If it's going to survive, it needs to be more open with its community, just as a start. Like a roadmap or even some idea what SMF 2.1 is supposed to be... it's only been 20 months in the making and no-one outside of Github reviewers really knows what's actually in it. There are some vague comments about new features but it's hardly much more than straight up marketing spiel.
For any project that would be fairly poor, but for a project that spent so much time trying to claim it is open, that's truly poor. It is also a major contributing factor.
Here's one thing some people don't seem to understand: Wedge is a closed project. We are, and have always been, hesitant to accept contributions from third parties, we haven't revealed a roadmap or anything... but 1) we've always made it clear that we have the role of benevolent dictators for Wedge and 2) we do actually involve our community in things. I suggest new ideas and features at least once a week specifically for community involvement in shaping those ideas.
Contrast this to SMF: a project that claims to be open, that has an organisation to support project development, with a project team of about two dozen people (which is low, I remember it at times being 40+). On top of that there is a Board of Directors who makes decisions that not even the team are fully made aware of, even as organisation members. (Because that's good, right?) They're not even open amongst themselves, let alone open with the community as a whole.
No plans have been announced for 2.1 development as such, or indeed anything beyond that. Truth of the matter: the lead dev in 2.0 didn't even want 2.1 to exist. I understand that - she wanted SMF to progress on smCore and devote all its time to that. The project had a rumbling and decided that 2.1 was necessary to prevent SMF falling even further behind - with the understanding that smCore + SMF would be at least 2 years away from that point. And so it came into being - in 2011. Except here we are in 2013 and only alphas of a 'small incremental release' have been hinted at, and nothing beyond 2.1 has been even mentioned, as smCore is clearly defunct now. (But again, lack of transparency about all of this.)
I understand that development is slow, I understand that only too well. But why is there no real communication about the roadmap? I'm not asking for chapter and verse, or pointing fingers at people for not doing their job properly. I'm just trying to point out that this organisation is failing to do a key job in onward development. (Our changelog is very public.)
At this point you can turn around and say that we haven't released a roadmap either and that we could be called hypocritical. It'd also be wrong, but you could claim it. The entire thing is one long rolling upgrade at this point in time. We can't tell you exactly what Wedge 1.0 will be, because it's still growing and evolving. Setting arbitrary boundaries at this stage would actually limit what we do. Right now we're still figuring out some of the key things we want to have. But what we do have is very public and we encourage discussion on it.
While we're on the name calling angle, actually, there is a claim from certain members of the project that people like me and Norv have 'more credibility' than the SMF team and 'how evil they must be' and so on.[2] It's all bullshit.
The reason we have more 'credibility' is because we don't do stuff in private much, neither Wedge nor ElkArte.[3] We try to involve everyone where possible. We certainly don't sit in a tower on high making decisions about things, especially things that we aren't going to get involved with making. You don't see a project sitting above Nao and myself telling us what we should be writing.
But more than that, I'm not interested in killing SMF. I never have been. I saw back in 2009 when I first joined the team that it was in trouble. It's still there, despite everything I'd done in the meantime, despite everything Norv did, despite everything that's happened - it's still in trouble. If I genuinely thought SMF was so poor and I wanted it to die, why did I spend a lot of time on support issues? Could it be because somewhere, I still care? Nah, that would controvert this idea that I want SMF to die, and god forbid we should let the truth get in the way of a righteous smiting.
I should also add, I have heard it said that the community shouldn't have been made aware of the drama in the team in the past. Except this to me is a colossal problem. That implies that the team are not part of the community. That they're somehow removed from the community. Now, the team are all heavyweight contributors to the project, I have no beef with that. What I have a problem with is the notion that being long-time contributors somehow makes their opinion more important than the rest of the community's.
Compare and contrast that with Wedge. There are only two people in this project whose opinion outweighs everyone else's. There is also a small group of people whose opinion outranks others. This is not really a secret. But let me explain how it works.
The top two people are Nao and myself. We write the vast bulk of Wedge's code. That gives us final say on what happens. The reason, then, that our opinion is more important is not because we have inflated egos or anything but because we're the ones *actually doing it*.
The second group of people I mention are the Consultants. The reason they have an opinion we pay more attention to is because, again, they're actually doing it. They're looking at the code, they're actively writing code that has been taken under consideration and in some cases even drafted into the core. Again, because they're actually getting down and dirty with the code, we pay them some extra attention.
Then there's everyone else. It is not to say that we don't listen - because we certainly do. We listen to every comment and every thread that gets made. We're not under any prerogative to accept it, just as I'm not under any prerogative to accept any code Nao writes and he, I, vice versa.
Compare this with SMF. They have a vast group of people who are not code authors, who are not getting down into the code suggesting how things could/should/must be done. Why is their opinion more important than the regular users? Should it be so? I'd say not... you can be a major contributor without being a 'team member'. I've proved that. I can happily make thousands of posts without being a team member or without having a badge, and my opinion is considered as valid as a team member's in most cases because it's backed up by experience and/or code. So the badge is not a requirement. It is the worst kind of meritocracy, the self-serving, self-selecting kind.
So with the latest salvo (e.g. Motoko's snide comments, and the comment about the only place I want to see SMF is down the drain), I might as well just leech off sm.org rather than contribute because it's increasingly clear my comments aren't wanted.[4] Since the management is already convinced that I'm desperately trying to kill SMF, I might as well indulge them in that by taking Wedge so far beyond SMF that it'll never catch up. Then it can die a quiet, hopefully painless death because that's the best it can hope for now.
There's the gauntlet, folks, thrown down, right there.
:edit: by Nao: both clarified and concealed topic subject... :eheh:
| 1. | Norv and I don't exactly get on, but we do have some mutual respect for the position each other holds. I have other issues with some of the things she has said and done, however for me at least, most of them are in the past. |
| 2. | Again, notice this hasn't been said in public. The only public comment is how according to one team member, Norv is just delusional. She's not, of course. She's just more hardline about things and I'm pretty convinced that she's right about a lot of things in this whole matter. But hey, I've been called wilfully dense by the team before, it's only a matter of time before I'm called delusional too. |
| 3. | We did in the early days. But right now almost everything of the stuff happens in public and that's entirely by design. |
| 4. | Their bug reports, their feature suggestions etc. |
71
Archived fixes / Outgoing emails aren't passed through the rewriter
« on February 22nd, 2013, 06:11 AM »
This is potentially very awkward.
For starters, PM notifications (even before my tweaks) were set up to reply to $scripturl . ?action=pm;stuff and that still comes out in the emails. It also means we can't streamline those with <URL> replacements.
On top of that it also means that internal links won't be prettified in any fashion.
What we need to do then is have the entire rewrite buffer be encapsulated in a function that we can pass arbitrary content to and have it prettified? Seems to me that email content would need that. (And it should all be pushed into loadEmailTemplate these days, even those damn PM notifications)
For starters, PM notifications (even before my tweaks) were set up to reply to $scripturl . ?action=pm;stuff and that still comes out in the emails. It also means we can't streamline those with <URL> replacements.
On top of that it also means that internal links won't be prettified in any fashion.
What we need to do then is have the entire rewrite buffer be encapsulated in a function that we can pass arbitrary content to and have it prettified? Seems to me that email content would need that. (And it should all be pushed into loadEmailTemplate these days, even those damn PM notifications)
72
Features / Micro feature: escliteral type
« on February 21st, 2013, 02:10 AM »
So, we have escaped strings, e.g. we use {string:blah} and that's going to look for a variable 'blah'. Surprisingly often that will turn out to be 'blah' in the parameters, e.g. we needed the content to be as is, but merely string escaped for queries.
So I'm wondering, is it worth having the case where we define {escliteral:string} to have 'string' appear in the query properly escaped?
Primarily wondering what the coders are likely to make of it... Nao, Dragooon, live, thoughts? It's just a convenience feature really.
So I'm wondering, is it worth having the case where we define {escliteral:string} to have 'string' appear in the query properly escaped?
Primarily wondering what the coders are likely to make of it... Nao, Dragooon, live, thoughts? It's just a convenience feature really.
73
Archived fixes / Serious error - current theme
« on February 20th, 2013, 12:13 AM »
For some reason when Current Theme is triggered, and only Current Theme (not the entire Themes and Layout section, it's only the theme settings for an actual theme), something is broken whereby it proceeds to dump the entirety of all language strings, vomiting 95 errors into the log.
I'll look into this one tonight as part of my language changes in general.
I'll look into this one tonight as part of my language changes in general.
74
Features / Guess the Feature
« on February 19th, 2013, 06:05 AM »
So I'm working on a new feature and as ever this means new UI, and I suck at UI.
But here's the WIP as it stands. I'm sure you'll have no difficulty guessing what feature this is (first picture is older than second, it's still evolving and nothing is set yet)
But here's the WIP as it stands. I'm sure you'll have no difficulty guessing what feature this is (first picture is older than second, it's still evolving and nothing is set yet)
75
Features / facepalm or headdesk smiley
« on February 18th, 2013, 01:31 AM »
I don't mind which we have, but I believe we need at least one of these in the core distribution.