Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Arantor
5101
Plugins / Re: Plugins NOT modifying core files
« on January 12th, 2012, 09:03 AM »Well sure. Maybe they could edit non-core files though?
In any case, if you don't implement this ability, how about getting rid of the SFTP file? :eheh:
5102
Plugins / Re: Exposing bbcode to the plugin manager
« on January 12th, 2012, 09:01 AM »
Ah, patience, patience! It's all inter-related in my head!
I'm still trying to decide whether the enable/disable bbcode needs to work per tag (like it does currently, that disabling 'quote' disables all the variants of 'quote') or per individual bbcode.
I'm still trying to decide whether the enable/disable bbcode needs to work per tag (like it does currently, that disabling 'quote' disables all the variants of 'quote') or per individual bbcode.
5104
Plugins / Re: Exposing bbcode to the plugin manager
« on January 12th, 2012, 03:37 AM »
Note to self: this will be greatly helped if the internal bbcode editor also provides for showing the XML block, meaning that mod authors can build it in the normal editor, test it on their forums, and package it very, very quickly.
5105
Plugins / Re: Exposing bbcode to the plugin manager
« on January 12th, 2012, 02:52 AM »* Lurker is working on this right now.
The id in the column is also not a performance concern because it won't materially affect the query to actually load it.
Posted: January 12th, 2012, 02:40 AM
Holy monkey bladders is there a lot of rules for the XML for this, just for validity checking (that's even before I get into the full code for the plugin manager, but it'll be worth it)
5106
Plugins / Re: Show Hooks
« on January 12th, 2012, 02:43 AM »
Also, I like the interface better now I can see it.
Might I suggest two separate views for this? The current one gives you the hooks split by different plugins, but I'm also thinking it might be useful to have the hooks just in their own order.
Incidentally, to really make use of that it would be handy if we had some way of classifying hooks (like is done in the comments currently, but more formally so), so that we could group them by functionality (and for hooks added by plugins, we could break them down by plugin that adds hooks)
Hmm, more thought required.
Might I suggest two separate views for this? The current one gives you the hooks split by different plugins, but I'm also thinking it might be useful to have the hooks just in their own order.
Incidentally, to really make use of that it would be handy if we had some way of classifying hooks (like is done in the comments currently, but more formally so), so that we could group them by functionality (and for hooks added by plugins, we could break them down by plugin that adds hooks)
Hmm, more thought required.
5107
Plugins / Plugins NOT modifying core files
« on January 12th, 2012, 02:26 AM »
I've been thinking about this lately after cruising around sm.org, and the more I think about it, the more I don't want files being edited by plugins.
If a plugin requires a core edit, the user should have to do that themselves. We lose the ability to do quick patches SMF style, but I'm not convinced that's a bad thing either.
What finally made me change my mind? The number of reports of 'my site's been hacked'. Sure, on shared hosting you're definitely at more risk than you are on a VPS, but there is an inherent risk on a shared host that is made distinctly worse by having to change the file permissions, especially as people will often go away and change them to be writable generally when they don't need to, to avoid hassle in the future.
By limiting the scope of what is needed to be edited, the core files never need to be handled in that way.
The only argument that is on the other side of the fence is about people doing raw changes, but firstly if you are doing raw changes, that puts the onus on you to back up and so on. And it puts the onus on you to remember the changes you made.
Thing is, WP acts like this and it seems to be tolerated over there, but what happens is that the automated update actually can tell you what files are changing and you can then go away and figure out for yourself whether you should or should not deal with that.
I have no problem telling users that if they're going to modify the core software, they're responsible for the consequences, but I'm not going to babysit them for upgrading. There are good reasons why hacking the core shouldn't be done, and I'm finally convinced beyond doubt now that the benefits are easily outweighed by the problems attached.
If a plugin requires a core edit, the user should have to do that themselves. We lose the ability to do quick patches SMF style, but I'm not convinced that's a bad thing either.
What finally made me change my mind? The number of reports of 'my site's been hacked'. Sure, on shared hosting you're definitely at more risk than you are on a VPS, but there is an inherent risk on a shared host that is made distinctly worse by having to change the file permissions, especially as people will often go away and change them to be writable generally when they don't need to, to avoid hassle in the future.
By limiting the scope of what is needed to be edited, the core files never need to be handled in that way.
The only argument that is on the other side of the fence is about people doing raw changes, but firstly if you are doing raw changes, that puts the onus on you to back up and so on. And it puts the onus on you to remember the changes you made.
Thing is, WP acts like this and it seems to be tolerated over there, but what happens is that the automated update actually can tell you what files are changing and you can then go away and figure out for yourself whether you should or should not deal with that.
I have no problem telling users that if they're going to modify the core software, they're responsible for the consequences, but I'm not going to babysit them for upgrading. There are good reasons why hacking the core shouldn't be done, and I'm finally convinced beyond doubt now that the benefits are easily outweighed by the problems attached.
5108
Plugins / Re: Show Hooks
« on January 12th, 2012, 01:47 AM »
...ok, now I'm confused. I have no idea why that should be.
(Honestly, I get more than a shade confused by Aeva's permissions.)
(Honestly, I get more than a shade confused by Aeva's permissions.)
5109
Plugins / Re: Show Hooks
« on January 12th, 2012, 01:36 AM »
No worries :)
FWIW, the album should be set up so that anyone in the Consultants group can post images to it. I might end up posting some of mine to it sometime as and when I get time :/
FWIW, the album should be set up so that anyone in the Consultants group can post images to it. I might end up posting some of mine to it sometime as and when I get time :/
5110
Plugins / Re: Show Hooks
« on January 12th, 2012, 01:16 AM »
Huh, try that now.
* Lurker idly speculates this will want some UI love going forward.
5111
Plugins / Re: Show Hooks
« on January 12th, 2012, 01:00 AM »
Try it now. I created a new profile in the permissions that should allow you to upload to it.
5112
Plugins / Re: Show Hooks
« on January 12th, 2012, 12:31 AM »
Yes, I think you came up with a good UI, though it's hard to tell exactly what the screenshot is showing since it got resized on upload :/
5114
Plugins / Exposing bbcode to the plugin manager
« on January 11th, 2012, 01:44 PM »
I've been thinking a bit about the bbcode management side of things, and in particular ways that users can extend bbcode.
Yes, I want to make a custom bbcode interface part of the core, but I can also see the validity of plugins that provide bbcode either through conventional means or custom means (if they need to do things that aren't supported in the core, or some preparsing for example)
What I'm envisaging, then, is that the bbcode table might grow an id column to indicate where a bbcode has come from, and that there might be a direct interface in the plugin-info.xml file to actually add a bbcode that way.
Having the id in the table would allow cleanly removing bbcode from the table when disabling a plugin (something that is currently not entirely reliable), and it would certainly make it easier to package up new bbcode, even if users would otherwise just be able to insert bbcode themselves... some users really are lazy in that respect. :P
Yes, I want to make a custom bbcode interface part of the core, but I can also see the validity of plugins that provide bbcode either through conventional means or custom means (if they need to do things that aren't supported in the core, or some preparsing for example)
What I'm envisaging, then, is that the bbcode table might grow an id column to indicate where a bbcode has come from, and that there might be a direct interface in the plugin-info.xml file to actually add a bbcode that way.
Having the id in the table would allow cleanly removing bbcode from the table when disabling a plugin (something that is currently not entirely reliable), and it would certainly make it easier to package up new bbcode, even if users would otherwise just be able to insert bbcode themselves... some users really are lazy in that respect. :P
5115
FAQs / [FAQ] Re: What is Wedge?
« on January 11th, 2012, 12:47 PM »* Lurker just gets annoyed when people don't realise that deadlines are a fiction created by an arbitrary guess at the future based on incomplete data at the time and are thus entirely prone to being changeable.