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
91
Off-topic / Interesting concept
« on February 2nd, 2013, 07:28 PM »
http://gb.millionshort.com/
It's a search engine that removes the 'top 100, or top 1k, top 10k, top 100k or top 1m sites' from their result, the idea being to encourage people to find new things that aren't so popular.
Thoughts?
It's a search engine that removes the 'top 100, or top 1k, top 10k, top 100k or top 1m sites' from their result, the idea being to encourage people to find new things that aren't so popular.
Thoughts?
92
Bug reports / SMF bug: replying to topic with mismatch of replies
« on January 26th, 2013, 06:47 PM »
We all know that if you try to reply to a topic that has been replied to in the intervening time, you should get a message. But it won't do that if there is a mismatch the other way.
Specifically, when you try to reply to a topic, the number of replies in the topic is known to the reply page. And if the number of replies is greater, it will throw you the message.
But if there are less replies than it said, it won't give you a message. Specifically in my case, I replied to a thread, only to discover that the last half a dozen replies had been split off into another topic, leaving my reply to be an orphan.[1]
Need to investigate about checking for a mismatch either way rather than just > count.
Specifically, when you try to reply to a topic, the number of replies in the topic is known to the reply page. And if the number of replies is greater, it will throw you the message.
But if there are less replies than it said, it won't give you a message. Specifically in my case, I replied to a thread, only to discover that the last half a dozen replies had been split off into another topic, leaving my reply to be an orphan.[1]
Need to investigate about checking for a mismatch either way rather than just > count.
| 1. | And no, no amount of 'return me to my post' would have made it clear that that was what had happened either. |
93
Bug reports / Weaving & Warm issues in iOS
« on January 23rd, 2013, 04:55 PM »
Did you make it bigger? Everything seems bigger in Warm since the new link tree was added (on iPad 3, with Retina)
94
Off-topic / Plugin user interfaces
« on January 23rd, 2013, 01:05 AM »
Is it just me or do plugin authors generally write fairly poor user interfaces for their plugins/mods?
I know I did a few times, but usually because of keeping it straightforward to integrate into the ACP and minimise manual edits, but when I stretched my legs with SimpleDesk, I spent a fair amount of time writing a decent admin UI and I think it shows the effort that went into it.
Am I being overly cynical or are a lot of plugins lacking decent UI? Is this something we should try to discourage in Wedge?
I know I did a few times, but usually because of keeping it straightforward to integrate into the ACP and minimise manual edits, but when I stretched my legs with SimpleDesk, I spent a fair amount of time writing a decent admin UI and I think it shows the effort that went into it.
Am I being overly cynical or are a lot of plugins lacking decent UI? Is this something we should try to discourage in Wedge?
* Arantor has absolutely no restrictions about forcing plugin authors to produce decent user interfaces ;)
95
Plugins / Plugin server
« on January 21st, 2013, 12:00 AM »
So I've been wrangling with this, and I don't see any way around what needs to be done for this.
Specifically, as nice as it is using Aeva, I don't believe that we can meaningfully use that on a production site, because there's a bunch of meta information that's required, not to mention the fact that the nature of private repositories requires providing a login and ideally without having to actually do the usual run of actually logging in.
Not to mention the nature of serving plugins and so on carries a performance hit that I'd rather not carry on the main server (especially as in the future I plan to have plugins query for updates and that's going to be expensive). We can use a subdomain if we wanted to, I also own wedgeplugins.com/.net/.org just in case.
So, let me explain the entire nature of the plan I have, and then we'll deal with questions.
I plan to run a separate plugin repo, on a separate Wedge install to here. This is to isolate performance issues. In fact, there's no reason why - with what I'm about to say - that it even needs to be on the same physical server. From a performance perspective it may even be better if it is not. I'll come back to this in a minute.
So, plugin server serves three types of requests from repos, it serves: simple list of plugins (be that in categories or otherwise), actually serving the plugin, and searching for plugins.
The architecture I have in mind will even allow for private plugins and so on, quite happily, the user provides their username/password when adding the repo. It sends the details when making a request as part of the request (in a very encoded form, of course), and authentication is done there.
As far as the 'separate server' gig, that's not a huge deal. Some people here will be familiar with the concept of IP.Connect; this is the principle plan I have, to use the second server as a slave using the IP.Connect protocol to connect to this site (this means you have two sites that have conjoined accounts in a sense)
Alternatively if third party sites want to set up their own repos, that's an option too.
Mechanically, we're talking about a plugin that accepts requests to action=plugins and handles the requests from there. Mostly that's straightforward requests, but here's the clever part: we can easily make this a complete 'mod site' as was, including comments/support, approvals or whatever and creating boards/topics as needed.
It just seems to me that doing it on a separate site is actually a stronger proposition than trying to manage it here in the long run, especially in performance terms. Given how much trouble people have with sm.org, it actually seems to me that having proper separation is actually more of an advantage than not separating it.
I'm also thinking this will help shift some of the 'perceived liability' especially if this other site becomes a sort of marketplace of sorts, which is ultimately where I hope to go with it.
Any questions?
I should add, it would not be terribly difficult for me to drop all repo handling and just leave it to people to browse the site etc. But this seems more professional to have it integrated. I would not lose *that* much sleep if the opinion were overwhelmingly against worrying about having integration into the core.
Most of this is stuff that needs to be done either way, though.
Specifically, as nice as it is using Aeva, I don't believe that we can meaningfully use that on a production site, because there's a bunch of meta information that's required, not to mention the fact that the nature of private repositories requires providing a login and ideally without having to actually do the usual run of actually logging in.
Not to mention the nature of serving plugins and so on carries a performance hit that I'd rather not carry on the main server (especially as in the future I plan to have plugins query for updates and that's going to be expensive). We can use a subdomain if we wanted to, I also own wedgeplugins.com/.net/.org just in case.
So, let me explain the entire nature of the plan I have, and then we'll deal with questions.
I plan to run a separate plugin repo, on a separate Wedge install to here. This is to isolate performance issues. In fact, there's no reason why - with what I'm about to say - that it even needs to be on the same physical server. From a performance perspective it may even be better if it is not. I'll come back to this in a minute.
So, plugin server serves three types of requests from repos, it serves: simple list of plugins (be that in categories or otherwise), actually serving the plugin, and searching for plugins.
The architecture I have in mind will even allow for private plugins and so on, quite happily, the user provides their username/password when adding the repo. It sends the details when making a request as part of the request (in a very encoded form, of course), and authentication is done there.
As far as the 'separate server' gig, that's not a huge deal. Some people here will be familiar with the concept of IP.Connect; this is the principle plan I have, to use the second server as a slave using the IP.Connect protocol to connect to this site (this means you have two sites that have conjoined accounts in a sense)
Alternatively if third party sites want to set up their own repos, that's an option too.
Mechanically, we're talking about a plugin that accepts requests to action=plugins and handles the requests from there. Mostly that's straightforward requests, but here's the clever part: we can easily make this a complete 'mod site' as was, including comments/support, approvals or whatever and creating boards/topics as needed.
It just seems to me that doing it on a separate site is actually a stronger proposition than trying to manage it here in the long run, especially in performance terms. Given how much trouble people have with sm.org, it actually seems to me that having proper separation is actually more of an advantage than not separating it.
I'm also thinking this will help shift some of the 'perceived liability' especially if this other site becomes a sort of marketplace of sorts, which is ultimately where I hope to go with it.
Any questions?
Posted: January 20th, 2013, 11:57 PM
I should add, it would not be terribly difficult for me to drop all repo handling and just leave it to people to browse the site etc. But this seems more professional to have it integrated. I would not lose *that* much sleep if the opinion were overwhelmingly against worrying about having integration into the core.
Most of this is stuff that needs to be done either way, though.
97
Plugins / Forcing maintenance mode first?
« on January 20th, 2013, 08:38 PM »
For most plugins, it's no big deal to do their installation, even down to creating new tables and so on.
But plugins that modify tables, especially if they're going to modify big tables that are heavily used (topics, messages, members), it seems to me that it might be worth enforcing the site is in maintenance mode before installing such (because the tables will be locked during that time)
I'm sort of torn on whether this is needed or not (though I think it is certainly useful), and though part of me is tempted to enforce it, I think what I'd rather do is leave it to the plugin author whether they want to use it.
What I'd do in that case is provide an attribute somewhere which indicates what action/actions require maintenance mode or not, for example, <plugin id="Arantor:plugin" maintenance="enable,remove-clean"> to mirror the possible scripts that something could run; typically only enable and remove-clean are the times this is an issue anyway since it is enable and remove-clean that invariably are schema changing.
Thoughts?
But plugins that modify tables, especially if they're going to modify big tables that are heavily used (topics, messages, members), it seems to me that it might be worth enforcing the site is in maintenance mode before installing such (because the tables will be locked during that time)
I'm sort of torn on whether this is needed or not (though I think it is certainly useful), and though part of me is tempted to enforce it, I think what I'd rather do is leave it to the plugin author whether they want to use it.
What I'd do in that case is provide an attribute somewhere which indicates what action/actions require maintenance mode or not, for example, <plugin id="Arantor:plugin" maintenance="enable,remove-clean"> to mirror the possible scripts that something could run; typically only enable and remove-clean are the times this is an issue anyway since it is enable and remove-clean that invariably are schema changing.
Thoughts?
98
Archived fixes / Previous/next topics don't work properly
« on January 19th, 2013, 02:37 AM »
The query logic is actually very broken - but it's taken me this long to notice it. Part of the problem is understanding what desired behaviour is and what we actually get.
Against a board of non pinned posts, there's no problem, and there's never been a problem. But when you cross the pinned barrier, it all goes to hell.
For example, 'When can I download Wedge?' is the most replied to pinned topic in /pub/, last reply Jan 12th.
The 'next' topic is the one next chronologically on from it, which is about half way down the board, while the 'previous' topic is quite rightly the previous sticky topic.
Now I pick an unpinned topic from earlier. The 'next' topic is correct, but the 'previous' topic is the pinned topic that happens to be the most recent one prior to the date of the topic in question, if that makes sense (I picked a post from mid December, which pre-dates When can I download Wedge's last reply, but is after Read This First's last reply)
And this is even before I apply non-1 values to is_pinned >_<
It sort of depends on what the behaviour should be, I'm guessing when you reach the most recent topic in a given board that is non pinned, the next one *should* be the oldest/bottom-most pinned topic?
As in, previous/next are effectively traversal up the message index as presented?
Against a board of non pinned posts, there's no problem, and there's never been a problem. But when you cross the pinned barrier, it all goes to hell.
For example, 'When can I download Wedge?' is the most replied to pinned topic in /pub/, last reply Jan 12th.
The 'next' topic is the one next chronologically on from it, which is about half way down the board, while the 'previous' topic is quite rightly the previous sticky topic.
Now I pick an unpinned topic from earlier. The 'next' topic is correct, but the 'previous' topic is the pinned topic that happens to be the most recent one prior to the date of the topic in question, if that makes sense (I picked a post from mid December, which pre-dates When can I download Wedge's last reply, but is after Read This First's last reply)
And this is even before I apply non-1 values to is_pinned >_<
Posted: January 19th, 2013, 02:32 AM
It sort of depends on what the behaviour should be, I'm guessing when you reach the most recent topic in a given board that is non pinned, the next one *should* be the oldest/bottom-most pinned topic?
As in, previous/next are effectively traversal up the message index as presented?
99
Features / Ordering sticky topics
« on January 16th, 2013, 05:11 PM »
Been thinking about this a bit, wondering what people think.
Would it be interesting/useful to allow site owners to re-organise sticky topics into a fixed order, regardless of last post?
Technically it makes little or no difference, ordering is always done on is_sticky which is a tinyint, and that's before ordering by last post. Right now, it's simply 1 or 0, but you could introduce non-1 values to force a specific ordering. It doesn't require changing indexes, since the nature of it will still mean zero rows will form the bulk of the index (and thus render it useless) and it is not significantly expensive to pull just the sticky rows from a board.
Just wondering if it's worth the effort; it's mostly just some UI and a little bit of logic change (where it currently assumes it's 1/0 rather than non-zero/zero)
Would it be interesting/useful to allow site owners to re-organise sticky topics into a fixed order, regardless of last post?
Technically it makes little or no difference, ordering is always done on is_sticky which is a tinyint, and that's before ordering by last post. Right now, it's simply 1 or 0, but you could introduce non-1 values to force a specific ordering. It doesn't require changing indexes, since the nature of it will still mean zero rows will form the bulk of the index (and thus render it useless) and it is not significantly expensive to pull just the sticky rows from a board.
Just wondering if it's worth the effort; it's mostly just some UI and a little bit of logic change (where it currently assumes it's 1/0 rather than non-zero/zero)
100
Features / Latest WIP: news feature
« on January 15th, 2013, 11:16 PM »
So, the news feature has bugged me for a while. So I'm fixing it up.
Firstly, reordering it. While the one-line display is randomised, the newsfader is not randomised, it follows through the order given. So you can reorder it.
Secondly, permissions. Right now news is 'everyone'. I've wanted it to separate out permissions for a while, but I don't think the whole gamut of permissions/groups is needed, so we have everyone, signed-in members, people who can moderate, people who are admins.
Thirdly, changing the UI generally. I don't know why I dislike the UI as much as I do, but it seems like a cop-out to me to have it as a series of textboxes like that, so a simple list of items, with modify buttons - plus a shiny modify button. Which will all go to a nice edit window with the editor component in it too.
I also haven't ruled out having it draw instead from a board or boards yet. Not sure how that's going to work exactly. But in the meantime here's a sneak peek.
Firstly, reordering it. While the one-line display is randomised, the newsfader is not randomised, it follows through the order given. So you can reorder it.
Secondly, permissions. Right now news is 'everyone'. I've wanted it to separate out permissions for a while, but I don't think the whole gamut of permissions/groups is needed, so we have everyone, signed-in members, people who can moderate, people who are admins.
Thirdly, changing the UI generally. I don't know why I dislike the UI as much as I do, but it seems like a cop-out to me to have it as a series of textboxes like that, so a simple list of items, with modify buttons - plus a shiny modify button. Which will all go to a nice edit window with the editor component in it too.
I also haven't ruled out having it draw instead from a board or boards yet. Not sure how that's going to work exactly. But in the meantime here's a sneak peek.
101
Features / Pages: [1] 2 3 styling
« on January 15th, 2013, 07:27 PM »
I think we need to do something with this, especially now that places are increasingly ditching use of [1] etc.
I was debating trying to use the styling we have for the note/notewarn/notenice classes for it, but then I figured it'd look wrong unless all the numbers were also encapsulated.
In other news, this is still way too small for practical use on a mobile device. Even on an iPad 3 it's too small (mind you, on an iPad 3, not even the full width is used in landscape, even including sidebar), though I won't be opposed to making it bigger just in Wireless.
Thoughts?
I was debating trying to use the styling we have for the note/notewarn/notenice classes for it, but then I figured it'd look wrong unless all the numbers were also encapsulated.
In other news, this is still way too small for practical use on a mobile device. Even on an iPad 3 it's too small (mind you, on an iPad 3, not even the full width is used in landscape, even including sidebar), though I won't be opposed to making it bigger just in Wireless.
Thoughts?
102
The Pub / New maintenance task
« on January 12th, 2013, 05:56 AM »
Been thinking about this a bit, not entirely sure what it needs, but thought I'd suggest it.
It's been the case for a long time that plugins can't touch the core, and it's now the case that files don't end in ?> which means one of my original thoughts on this subject is no longer necessary.
But anyway. I was going to do a maintenance task, running say every other week, to scan the files. It would scan the files for things like rogue characters at the start or end of files (though with the lack of trailing ?> this is a bit more difficult), perhaps for common injection type things and report to the admin area.
I kind of see this as a new area above the 'New to Wedge' box that's there, maybe even replacing it, don't know yet, where the admin panel flags up some tasks that are needed. For example, it strikes me that it would be neat to include a monthly reminder to update your anti spam Q&A as a 'Things to do' page.
This isn't original; IPB does it, and it strikes me that having such a notification (similar to, but more prominent, the admin panel upgrade notification in SMF) would be beneficial in encouraging people to fix things.
I could go on to have it be popping up even on a fresh install as 'You haven't set questions yet...' like a sort of warning. I'm getting a bit ahead of myself *rerail!*
So, maintenance task doing a health check. It could also conceivably do checking of file dates now that the core files don't need to be touched, except for Subs-Aeva-Sites.php which gets rewritten on updating the active site list. (Need to fix that. It causes havoc on systems that lock permissions down, not to mention the fact that having a core file be writable is asking for trouble.)
Comments?
It's been the case for a long time that plugins can't touch the core, and it's now the case that files don't end in ?> which means one of my original thoughts on this subject is no longer necessary.
But anyway. I was going to do a maintenance task, running say every other week, to scan the files. It would scan the files for things like rogue characters at the start or end of files (though with the lack of trailing ?> this is a bit more difficult), perhaps for common injection type things and report to the admin area.
I kind of see this as a new area above the 'New to Wedge' box that's there, maybe even replacing it, don't know yet, where the admin panel flags up some tasks that are needed. For example, it strikes me that it would be neat to include a monthly reminder to update your anti spam Q&A as a 'Things to do' page.
This isn't original; IPB does it, and it strikes me that having such a notification (similar to, but more prominent, the admin panel upgrade notification in SMF) would be beneficial in encouraging people to fix things.
I could go on to have it be popping up even on a fresh install as 'You haven't set questions yet...' like a sort of warning. I'm getting a bit ahead of myself *rerail!*
So, maintenance task doing a health check. It could also conceivably do checking of file dates now that the core files don't need to be touched, except for Subs-Aeva-Sites.php which gets rewritten on updating the active site list. (Need to fix that. It causes havoc on systems that lock permissions down, not to mention the fact that having a core file be writable is asking for trouble.)
Comments?
103
Plugins / Max smileys per post
« on December 31st, 2012, 04:40 AM »
Another quick one. I'll add the package for the beta testers in a minute. Fairly straight forward, expand the moderation filters to be able to detect based on the number of smileys in a post.
I suspect there's possibly a clash in WYSIWYG cases, but for normal posting it's absolutely fine.
I suspect there's possibly a clash in WYSIWYG cases, but for normal posting it's absolutely fine.
104
The Pub / I can add... oh wait...
« on December 31st, 2012, 03:12 AM »
This is something that happens to me increasingly often - where I think... oh, I can go and implement that, and then I realise that maybe I don't need to.
Case in point, it just occurred to me that it might be nice to restrict posting of mass ? and ! in topic titles - but make it an option. So there I was, digging up the relevant code, and it hits me, admins can restrict it in the moderation filters area should they want to. It won't auto truncate, but you could add a rule preventing someone from making a post with 'HELP!!!!!!!!!!!!!!!!!' as the title having all those exclamation points.
I think, for this particular case, I will actually make the auto-correction an option, rather than leaving it to the moderation filters, but it's surprising how often I come along and think... oooh, I don't need to write that, I can already do it <this way>.
Case in point, it just occurred to me that it might be nice to restrict posting of mass ? and ! in topic titles - but make it an option. So there I was, digging up the relevant code, and it hits me, admins can restrict it in the moderation filters area should they want to. It won't auto truncate, but you could add a rule preventing someone from making a post with 'HELP!!!!!!!!!!!!!!!!!' as the title having all those exclamation points.
I think, for this particular case, I will actually make the auto-correction an option, rather than leaving it to the moderation filters, but it's surprising how often I come along and think... oooh, I don't need to write that, I can already do it <this way>.
105
Bug reports / in_array() expects parameter 2 to be array
« on December 23rd, 2012, 11:44 PM »
Guest
Today at 10:29 PM
Type of error: General
http://localhost/wedge/index.php?localhost/wedge/index.php?action=admin;area=ban;sa=soft;ace465ae=80b35724d62f371a37399bdcebf8345e
2: in_array() expects parameter 2 to be array, null given
File: C:/wamp/www/wedge/Sources/Security.php
Line: 804
This is interesting. That particular line is:
Code: [Select]
That implies that we::$user['permissions'] never gets declared properly for guests. The code changes are so vast that I can't practically review them line by line. I'm not sure why the reported URL is even flagged, because I see no reason why it should be called.
What I need to do is extend error handling to be able to provide a full backtrace as well on errors. That might at least explain how we get to where we are.
Note: at no point have I been a guest in this installation; I've been logged in as an admin the whole time.
Today at 10:29 PM
Type of error: General
http://localhost/wedge/index.php?localhost/wedge/index.php?action=admin;area=ban;sa=soft;ace465ae=80b35724d62f371a37399bdcebf8345e
2: in_array() expects parameter 2 to be array, null given
File: C:/wamp/www/wedge/Sources/Security.php
Line: 804
This is interesting. That particular line is:
if (!is_array($permission) && in_array($permission, we::$user['permissions']))That implies that we::$user['permissions'] never gets declared properly for guests. The code changes are so vast that I can't practically review them line by line. I'm not sure why the reported URL is even flagged, because I see no reason why it should be called.
What I need to do is extend error handling to be able to provide a full backtrace as well on errors. That might at least explain how we get to where we are.
Posted: December 23rd, 2012, 11:37 PM
Note: at no point have I been a guest in this installation; I've been logged in as an admin the whole time.