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
121
Features / Improving how smileys are managed
« on November 26th, 2012, 04:12 AM »
So, this was raised ages ago in the private area, and I want to bring it back for discussion. It is, after all, something of a mess.
First question: do we really need the facility for multiple smiley sets?
Second question: do we really need to ensure the same smileys are present in every set?
Third question, and this is one for the programmers rather than anyone else: can we safely ditch the predefined smileys shtick? Spoiler because it's long, messy and of little importance to most people, other than the UI aspect which I'll deal with afterwards.
(click to show/hide)
I mentioned a UI problem. Adding a new smiley is incredibly unintuitive.[1]
So, if we don't have customised smileys, because internally it's *all* that customised gig, we get to massively streamline the UI. Depending on how the above other questions turn out.
Also: as far as I'm concerned you will have to use FTP/SFTP credentials to upload files. I really hope that's not a problem for anyone because I'm not prepared to budge on that; the whole point is to NOT have to change file permissions and thus encourage people to make things insecure by design.
Thoughts welcome.
First question: do we really need the facility for multiple smiley sets?
Second question: do we really need to ensure the same smileys are present in every set?
Third question, and this is one for the programmers rather than anyone else: can we safely ditch the predefined smileys shtick? Spoiler because it's long, messy and of little importance to most people, other than the UI aspect which I'll deal with afterwards.
So, smileys have the predefined list hardcoded into the smiley code in a bunch of places, so that we don't have queries when we don't need them, except that anyone who uses customised smileys in any fashion - and that's probably most people who don't have a 'businessy' site - will be using customised smileys, and thus the performance aspect.
I seem to remember that it is cached, but that's not a hard thing to check and enforce. And even if we do have the whole multiple smiley sets (which I'm not entirely convinced needs to remain but I'm willing to go with the majority), it's not like we can't just cache everything and be done with it.
So there is a performance trade off for people who do use it, versus less hit for people who don't, but then we have the UI aspect...
I mentioned a UI problem. Adding a new smiley is incredibly unintuitive.[1]
So, if we don't have customised smileys, because internally it's *all* that customised gig, we get to massively streamline the UI. Depending on how the above other questions turn out.
Also: as far as I'm concerned you will have to use FTP/SFTP credentials to upload files. I really hope that's not a problem for anyone because I'm not prepared to budge on that; the whole point is to NOT have to change file permissions and thus encourage people to make things insecure by design.
Thoughts welcome.
| 1. | In fact, one of my side projects is a heavily modified SMF install (there's enough custom code that I don't want to have to keep patching to keep it level with Wedge, and I don't even see my keeping it beyond SMF 2.0). For reasons I won't get into, this project's smiley set was made out of a single sprite sheet, so I crudely replaced the code in SMF with that image and offsets and whatnot, and I showed the other folks involved on the project the UI, showing off the different smileys and all the codes attached to it - and the take-away comment was "I like the whole admin control. I wish SMF had such." - as in he thought I'd made the entire UI for customised smileys, solely because no-one had mentioned to him about enabling them. |
122
Archived fixes / Undefined: ex_string in Class-CSS
« on November 15th, 2012, 04:19 AM »
Undefined variable: ex_string in C:\wamp\www\wedge\Sources\Class-CSS.php on line 800
Points to:
Code: [Select]
This came up after trying to load my calendar CSS file in the admin panel. I'd note that at no other time has it given me this error - including since I last changed it.
Points to:
// Did we finish the file with an extends or unextends...? Immediately open it and close it.
if ((strpos($ex_string, ' extends ') !== false || strpos($ex_string, ' unextends ') !== false))
$tree .= " {\n}\n";
while ($level > 0)
{
$tree .= '}';
$level -= $indent;
}This came up after trying to load my calendar CSS file in the admin panel. I'd note that at no other time has it given me this error - including since I last changed it.
123
The Pub / Practical plugins problem with WeCSS
« on November 14th, 2012, 03:00 AM »
So I'm working on the plugin system and a problem hits me. I want to display three calendars in a row together at times. No bother, I thought, I seem to remember three-columns being declared for that, but it was obviously a long time ago because it's no big deal.
So, I thought, fine, I'll copy the definition for two-columns and adjust the width... except I can't, because you can't use extends in a plugin's CSS file to extend something in the main files. There's all kinds of good reasons for that, mostly that you don't want to potentially make exponential CSS files to cover for each combination of plugin where the files are loaded (three plugins will potentially generate 8 variations of everything)
That also rules out using inline-block as a base for extending (since that's what I really need here), so I figured I'd pull it in as a class, except I can't because it's defined as a virtual style (which means there's several loose places in the source where it IS used that need to be fixed)
Now, it's not a huge deal, I can use display: inline-block and only cut out IE6/7, and for a plugin I'm cool with that - but it does irk me that something that is in the core, I can't meaningfully use in a plugin. I also don't know how to get around it but I'm getting it out here in case someone does have an idea.
So, I thought, fine, I'll copy the definition for two-columns and adjust the width... except I can't, because you can't use extends in a plugin's CSS file to extend something in the main files. There's all kinds of good reasons for that, mostly that you don't want to potentially make exponential CSS files to cover for each combination of plugin where the files are loaded (three plugins will potentially generate 8 variations of everything)
That also rules out using inline-block as a base for extending (since that's what I really need here), so I figured I'd pull it in as a class, except I can't because it's defined as a virtual style (which means there's several loose places in the source where it IS used that need to be fixed)
Now, it's not a huge deal, I can use display: inline-block and only cut out IE6/7, and for a plugin I'm cool with that - but it does irk me that something that is in the core, I can't meaningfully use in a plugin. I also don't know how to get around it but I'm getting it out here in case someone does have an idea.
124
OK, OK, don't get your hopes up. It's NOT going back in the core. NO.
However, while I let other things simmer until they're done, I'm curious to hear what people would like to see in the calendar.
I am not going to share what I have added or are going to add, but I do want to know what people think it should have. Remember, it's not a core feature, so the usual rules are less strict in this case.
It's basically that it needs some love and I feel in a giving-love kind of mood ;)
(I'm posting it here because I didn't want to get people thinking it was already out etc. because it's not.)
However, while I let other things simmer until they're done, I'm curious to hear what people would like to see in the calendar.
I am not going to share what I have added or are going to add, but I do want to know what people think it should have. Remember, it's not a core feature, so the usual rules are less strict in this case.
It's basically that it needs some love and I feel in a giving-love kind of mood ;)
(I'm posting it here because I didn't want to get people thinking it was already out etc. because it's not.)
125
Off-topic / Question of the day
« on November 8th, 2012, 05:09 AM »
Is it wrong that I find it *much* easier to write new table queries directly in SQL than to use the mess that phpMyAdmin has become?
Do you really need a draggable popup that contains the information needed to make columns? Do you have to make things so filling in every column requires many tabs, or worse lots and lots of dragging?
Do you really need a draggable popup that contains the information needed to make columns? Do you have to make things so filling in every column requires many tabs, or worse lots and lots of dragging?
126
Off-topic / XenForo lawsuit
« on November 6th, 2012, 04:35 AM »
Yup, vBulletin is STILL in the process of suing XenForo, and I mention this because today was supposed to be a big day - the day when the motion to dismiss was heard in the court and subsequently denied, so vBulletin's owner and XenForo are going to go to court in January.
Combined with how bad vB 5 is turning out to be, you'd think more groups would try and take advantage of this situation...
Combined with how bad vB 5 is turning out to be, you'd think more groups would try and take advantage of this situation...
127
The Pub / Hardening admin security
« on November 5th, 2012, 05:59 PM »
Another random idea.
So, when you go into the admin panel, moderation panel or editing other users' profiles, you're required to revalidate your password for one hour.
Not so much the moderation panel or profiles, but for the admin panel, what if instead of re-entering your password, it sent you an email with a one-time use code, on provision of which you would get access to the admin panel?
Same deal otherwise - revalidate an hour later. But that it is something a bit stronger than just your password. Reason that I suggest this, is if you have someone trying to force their way into the admin panel, they would have to do more than just brute force your password. (Quite a bit more, really)
Of course, it would be disabled by default, mostly for those of us on WampServer or whatever who don't have email servers set up ;) - if you already have access to the database anyway to be able to change this you're already powerful enough.
So, when you go into the admin panel, moderation panel or editing other users' profiles, you're required to revalidate your password for one hour.
Not so much the moderation panel or profiles, but for the admin panel, what if instead of re-entering your password, it sent you an email with a one-time use code, on provision of which you would get access to the admin panel?
Same deal otherwise - revalidate an hour later. But that it is something a bit stronger than just your password. Reason that I suggest this, is if you have someone trying to force their way into the admin panel, they would have to do more than just brute force your password. (Quite a bit more, really)
Of course, it would be disabled by default, mostly for those of us on WampServer or whatever who don't have email servers set up ;) - if you already have access to the database anyway to be able to change this you're already powerful enough.
128
Features / Something really strange just occurred to me
« on November 5th, 2012, 03:44 AM »
We've all commented in the past about the inanity of 'Regular Members', about the various issues with it and so on.
While working on the member groups configuration page, it just occurred to me - what if, for the sake of argument, Regular Members were to be an actual physical group?
It's not, in any real sense of the word, a physical group. You can't rename it. It doesn't show up on the left anywhere (which is, mostly, the reason for it being a phantom group). Users often want to put users into a specific group on registration - why not make it so they actually DO go into a physical group at registration rather than this phantom group?
Other than having to tweak some of the display code, not to mention some of the management logic (like preventing users deleting it, and to prevent it being changed to another kind of group), I see no reason not to do this.
On the flip side, it would allow you to do things you currently can't - you can't currently set the list of boards accessible to Regular Members as a whole group. You have to do that one board by board, even in SMF, because the edit-membergroup page only works on cases where the group id is 2 or 4+ (global moderator and any group that isn't guests, regular members, admin and board moderators)
I'd love to hear more opinions on this, especially from people who know the code base. I don't see that it should affect things that significantly anywhere.
While working on the member groups configuration page, it just occurred to me - what if, for the sake of argument, Regular Members were to be an actual physical group?
It's not, in any real sense of the word, a physical group. You can't rename it. It doesn't show up on the left anywhere (which is, mostly, the reason for it being a phantom group). Users often want to put users into a specific group on registration - why not make it so they actually DO go into a physical group at registration rather than this phantom group?
Other than having to tweak some of the display code, not to mention some of the management logic (like preventing users deleting it, and to prevent it being changed to another kind of group), I see no reason not to do this.
On the flip side, it would allow you to do things you currently can't - you can't currently set the list of boards accessible to Regular Members as a whole group. You have to do that one board by board, even in SMF, because the edit-membergroup page only works on cases where the group id is 2 or 4+ (global moderator and any group that isn't guests, regular members, admin and board moderators)
I'd love to hear more opinions on this, especially from people who know the code base. I don't see that it should affect things that significantly anywhere.
129
Features / Permissions UI
« on November 4th, 2012, 11:33 PM »
I've not been happy with the permissions UI for some time. There are a number of things I dislike about it.[1]
So, I have a suggestion. I haven't mocked it up or anything yet because it's still mentally a WIP but just hear me out.
You've probably seen the Detailed Reports area? The one where you get a list of every group and every permission? Well, if you're not familiar with it, I've attached an example.
What I'm imagining is essentially that screen, but with subdivisions for groups of permissions, sort of like in the Simple mode. So that you'd be able to see at a glance which groups have which permissions.
As far as changing it goes, I've had various ideas about that, but the one I'm happiest with would be where you could click on the cell you wanted to change it and it would pop up some option to let you change it. I'm thinking it would expand that cell to include either a dropdown (for yes/no/never), or slightly more controversially, two tickboxes, Allow and Deny.[2]
I'm not really fussed about the exact way the permissions selection bit would be, I'm more interested whether the overall deal of seeing permissions at once would be worth pursuing. As far as post count permissions goes, you'd have a button to switch from groups to post count groups and back, because there's only so much room on screen for it.
What do people think about this in general? Would like any clarifications?
Note also this might lead to the beginning of phasing out of the detailed reports - there's no need to have the report if you can get the same information elsewhere.
So, I have a suggestion. I haven't mocked it up or anything yet because it's still mentally a WIP but just hear me out.
You've probably seen the Detailed Reports area? The one where you get a list of every group and every permission? Well, if you're not familiar with it, I've attached an example.
What I'm imagining is essentially that screen, but with subdivisions for groups of permissions, sort of like in the Simple mode. So that you'd be able to see at a glance which groups have which permissions.
As far as changing it goes, I've had various ideas about that, but the one I'm happiest with would be where you could click on the cell you wanted to change it and it would pop up some option to let you change it. I'm thinking it would expand that cell to include either a dropdown (for yes/no/never), or slightly more controversially, two tickboxes, Allow and Deny.[2]
I'm not really fussed about the exact way the permissions selection bit would be, I'm more interested whether the overall deal of seeing permissions at once would be worth pursuing. As far as post count permissions goes, you'd have a button to switch from groups to post count groups and back, because there's only so much room on screen for it.
What do people think about this in general? Would like any clarifications?
Posted: November 4th, 2012, 11:31 PM
Note also this might lead to the beginning of phasing out of the detailed reports - there's no need to have the report if you can get the same information elsewhere.
| 1. | The fact there's a Simple and a Classic view, when neither are particularly wonderful. The fact that deny permissions is extra steps to enable. I could go on. |
| 2. | You have two tickboxes, allow and deny. Ticking the allow box gives the permission, ticking the deny box means deny as we know it normally, leaving both blank means not granting it, as we would call disallow. If you're unclear, this is what Windows uses for assigning things like sharing permissions. It works. |
130
Features / Changing topic/post owner
« on November 3rd, 2012, 06:29 PM »
Random idea: what if you could select a topic (or posts) to change the owner of?
I don't mean reattribution as per the current admin feature, but if you have a topic added by a moderator and then you change its owner to a generic 'team' account?
Would you rather this feature be a plugin or a core feature?
I don't mean reattribution as per the current admin feature, but if you have a topic added by a moderator and then you change its owner to a generic 'team' account?
Would you rather this feature be a plugin or a core feature?
131
Features / You will have to revalidate in...
« on November 3rd, 2012, 01:39 AM »
Something I've been thinking about lately, while working on some other stuff: the admin panel asks you to re-enter your password periodically.
What if, at the top of page, it also said: "You will be asked to re-enter your password in 58 minutes" or however long it would be?
Disclaimer: we found an old Christmas pudding in the cupboard. Best Before April 2012 it said, but it smelled OK, tasted OK when we heated it up... but it was already steeped in rum, brandy and sherry before we got to it, and it's had over a year to mature (so it's pretty ripe and alcoholic where the fruit has also fermented a bit)... so I'm a bit tipsy and as such the idea might have been a bit nonsensical.
In other news, I really need to write that 'I was drunk while posting this' plugin.
What if, at the top of page, it also said: "You will be asked to re-enter your password in 58 minutes" or however long it would be?
Disclaimer: we found an old Christmas pudding in the cupboard. Best Before April 2012 it said, but it smelled OK, tasted OK when we heated it up... but it was already steeped in rum, brandy and sherry before we got to it, and it's had over a year to mature (so it's pretty ripe and alcoholic where the fruit has also fermented a bit)... so I'm a bit tipsy and as such the idea might have been a bit nonsensical.
In other news, I really need to write that 'I was drunk while posting this' plugin.
132
Other software / Discussing Wedge on simplemachines.org
« on November 3rd, 2012, 12:00 AM »
Please can I ask everyone to refrain from doing this.
I was informed today that a thread had been started over there, and subsequently moved by the moderators, because they're afraid of proper competition - never mind the 'rules'. (You all know as well as I do that if we moved tomorrow to an open licence, nothing would change)
So, please, before the pissing contest gets any further out of hand, drop the subject. Don't get them any more ammunition to piss with. We have more important things to do than worry about them and their little sandbox.
Pragmatically, their pissing match has probably already backfired, since more people read Chit Chat than they do the Forks board, but I don't want to give them any ability to cause any more trouble than they can safely get themselves into.
I was informed today that a thread had been started over there, and subsequently moved by the moderators, because they're afraid of proper competition - never mind the 'rules'. (You all know as well as I do that if we moved tomorrow to an open licence, nothing would change)
So, please, before the pissing contest gets any further out of hand, drop the subject. Don't get them any more ammunition to piss with. We have more important things to do than worry about them and their little sandbox.
Pragmatically, their pissing match has probably already backfired, since more people read Chit Chat than they do the Forks board, but I don't want to give them any ability to cause any more trouble than they can safely get themselves into.
133
Archived fixes / Add plugin doesn't work
« on October 29th, 2012, 04:18 AM »
Sort of putting this in right here, right now.
None of the add plugin stuff works, mostly because I haven't figured out a way that doesn't suck that works without being insecure for uploading plugins.
None of the add plugin stuff works, mostly because I haven't figured out a way that doesn't suck that works without being insecure for uploading plugins.
134
Archived fixes / Popup event doesn't bubble properly
« on October 9th, 2012, 06:12 PM »
http://wedge.org/pub/plugins/7612/active-members/ is where I noticed it.
I clicked on the (1) to see the likes popup, which appeared over the top of the embedded image. But when I clicked on the Close button of the popup, the event was captured by the embedded image and triggered the expand there - and never propagated the event to the close button.
I clicked on the (1) to see the likes popup, which appeared over the top of the embedded image. But when I clicked on the Close button of the popup, the event was captured by the embedded image and triggered the expand there - and never propagated the event to the close button.
135
Archived fixes / Modify group does not show correct UI for board access
« on October 4th, 2012, 06:10 PM »
Some time ago I modified the way board access is handled, so that it is possible to exclude people from boards, as well as separating board visibility from board access.
I also updated the UI in manage boards to cover this, but the reverse option - setting what boards a given group can see - has not yet been updated, mostly because I haven't figured out a nice way to display it given the way board hierarchy can be handled and thus you need the ability to provide indentation and stuff...
I also updated the UI in manage boards to cover this, but the reverse option - setting what boards a given group can see - has not yet been updated, mostly because I haven't figured out a nice way to display it given the way board hierarchy can be handled and thus you need the ability to provide indentation and stuff...