Wedge

Public area => The Pub => Off-topic => Topic started by: [Unknown] on June 26th, 2011, 10:11 AM

Title: Unknown's thoughts on Wedge
Post by: [Unknown] on June 26th, 2011, 10:11 AM
Quote from Arantor on June 26th, 2011, 12:43 AM
FWIW, Notepad++ offers 1, 2, some of 3 (there's a popup display for the selection of tabs, much like Alt-Tab does but no jump-to-specific-tab-by-number), 4, 5 if you want, not sure about 6, 7 - well, it doesn't fail on 60MB SQL dumps but it doesn't like it much, 9, 11 and 12.
Quote from Nao/Gilles on June 26th, 2011, 07:52 AM
It has 8 too (clone view in tab context menu).
Hmm, it has 4 and 8?  I probably need to look at it again.  Sounds like it has improved.
Quote from Arantor on June 26th, 2011, 12:43 AM
It's not the uber-IDE but I've found it to be a very nice and capable tool, I certainly haven't found it wanting - except possibly for lack of an SVN plugin that doesn't require the SVN command line tools.
So using svn the way it was intended to be used (that is, via command line) is another beneficial feature it has, you say?  Sounds even better.

Heh, the GUIs bug me mainly because they make their own (different) choices than the developers of Subversion itself.  Example: TortoiseSVN iirc commits externals by default, whereas svn commit doesn't.  The correct way is what svn commit does, and I basically have to not use externals at work because everyone else uses the wrong and breaks them if I do (because they use TortoiseSVN.)

Meanwhile svn has excellent help, clean cli UI, and beats msysgit out of the part on Windows.  What more could I ask for?
Quote from Nao/Gilles on June 25th, 2011, 10:39 PM
And what do you think of our work from what you've seen so far? :unsure:
Well, I'm a nitpicker.  I could list a bunch of problems I have with SMF 2.0 in general, and with this, and even with the changes.  Not to mention just as many with code that is more or less certainly still code I wrote.  I also see it (and probably SMF 2 as well) as even more bloated than before, which I know you probably don't see as a bad thing...

Likely, I'm sure some people thought "my secret project" was bloated, what with its child boards and templates for each section (rather than just one global), etc.  So I'm certain I'm biased.

Anyway, staying away from the details, looking at the code (whether the new Wedge stuff or old) just makes me want to clean it up.  I don't know if you know, but I had a policy of re-reviewing files, periodically (on top of reviewing all incoming commits) which I did by marking files every X weeks and going through them line by line and making sure the code still jived together.

Are you guys doing code review at all yet?

Also, having managed sites that actually had multiple and seasonal themes, and enjoyed it and themes like the Comic theme, the direction I see those going saddens me.  Having written large scale modifications (which if I did it over again, I'd just make it take .diff files directly, in addition to a reasonable set of hooks, but then, the realities of PHP 4 got in the way of many things), and supported people who had very customized versions of SMF and YaBB SE, the direction that's going also greatly saddens me.

FWIW, if you wonder why I like the package manager, just so you know - the reason I joined the YaBB SE dev team was to improve the package manager and put it into Trinity (YaBB SE 2.0.)  Otherwise I would've never joined.  I like the concept of diff updates and being able to keep records of your changes (not that I don't like and desire plugins additionally, e.g. TOX-G is designed specifically with plugins in mind.)

And there I speak about SMF and Wedge, although in different ways.  I realize the "mods are only minor things" and "all themes are just colors changes of the default one" concepts come from somewhere.  Seems like a... not catch 22, whatever it's called when you assume a problem doesn't exist, because you don't have it, but really you don't have it for other reasons.  Seems like one of those whatever-they're-calleds to me, but that's just my opinion.

By the way, I suggest completely replacing setup_fatal_error_context() type operations with exceptions, since if you're requiring PHP 5, this will make integration much easier.  This was one of the big problems with SMF back in the day because of the PHP 4 requirement.  It's why lines like these exist:

Code: [Select]
trigger_error('Hacking attempt...', E_USER_ERROR);

Because I was working so hard to stop people from neutering their own forum's security measures.

Ah... just memory lane, mostly, for me.  Doesn't look different enough, just has stuff like PayPal all over it, which certainly makes the calendar look as much like a core feature as the "Reply" button.

-[Unknown]
Title: Re: Unknown's thoughts on Wedge
Post by: [Unknown] on June 26th, 2011, 10:35 AM
Quote from "[Unknown]" on June 26th, 2011, 10:11 AM
Hmm, it has 4 and 8?  I probably need to look at it again.  Sounds like it has improved.
Show-stopper: I can't drag files into it to open them.

Find and mark looks like a nice feature, though.

-[Unknown]
Title: Re: Unknown's thoughts on Wedge
Post by: Arantor on June 26th, 2011, 11:33 AM
Some interesting thoughts there.

In absence of anything else, the package manager means mod authors have to do direct edits to achieve things, rather than making use of facilities available. The main consequence of this is mods doing template edits which cause support issues because they then don't appear on some custom themes, or at least not the way they were intended. Adding to that, any theme that does do anything creative invariably fails, which is why so many themes are basically Curve knock-offs as opposed to anything more daring. (Yes, there were designers who do more daring things, but the vast bulk of the time the theme is just recoloured.)

And while there are some huge mods out there (Nao and Dragooon's Aeva Media, SimpleDesk by me and a couple of others, plus the portal mods), the vast bulk of mods are not that huge. There are mods now that simply remove the XHTML and RSS links from the footer, for example.
Quote
Seems like a... not catch 22, whatever it's called when you assume a problem doesn't exist, because you don't have it, but really you don't have it for other reasons.
You wonder if we're falling into the trap of "solving the wrong problem" as I tend to call it... well, the core reasons are pretty much as above. I know that's one of the reasons Bloc was so adamantly doing his own thing, but even there if you look at his custom themes (even his paid ones), they're still generally not that different, because he knows the reality of how many mods don't work on custom themes, and the support boards are full of it.

The lack of premium ecosystem for SMF also tells me there's a problem. There are currently two sites that I'm aware of, that provide paid-for themes (Bloc's site does not any longer). For a platform as entrenched as SMF is, there should really be more by now, but the fact is that there's no incentive for premium designers to design for SMF. Couple that with the fact that most people seem quite happy with vague recolourings with their own logo (which often doesn't really fit), and you begin to realise that the standard state of play is to run with what there is, rather than doing anything new.

As for mods, the situation there is marginally healthier, indicating that people generally would rather have new features than themes (at least, there is more effort put into mods than there is in themes, in general)

For example, just glance through the last submitted mods to the mod site:
* adding a user's birthday to their profile summary (in addition to the date which is there)
* specifying an alternative email address for outgoing mail, so that the admin's email isn't used for notifications
* a bugfix for the IE8 jumping text box problem, because obviously that couldn't have been added to 1.1.14/1.1.15 or similar
* two different mods for adding the Google +1 button, one for per-topic, one for per-post
* a nice FAQ mod
* a mod to replace the stats area at the bottom of the board index with a jQuery-based tab solution (which means adding jQuery, and will fail on any other theme/mod that already added jQuery)
* a mod to add several symbols as editor buttons (like 1/2, 1/4)
* putting the page number in the title of the page

As you can see, there's a couple of more complex mods, but for the most part there's nothing really that complicated or large in there. Over the three months I was on the Cust team, reviewing mods, the vast bulk of what came in were certainly in the 'small tweaks' category.


I would note that I have spoken to various theme and mod authors over the last two years and I'm hearing corroborating comments on the above. It boils down to the fact that there aren't the facilities to do most things without template changes, and if there were less template changes required, designers stand more chance of doing things that aren't just recolourings. It'll still happen, of course, but by removing one of the barriers that causes it, it should be possible for theme authors to do more interesting things, and by our approach of disallowing file edits from the add-on manager, modders will have to do things through hooks and other established methods - which means they won't be faced with having to do template edits.

That means if a particular mod and a particular theme don't play nicely, it's not related to the systemic issues currently in SMF and its environment, but it's that the theme does something the mod didn't expect, or vice versa - but it means that it can be dealt with on an individual basis. (Even WP has issues in this direction, I would note)
Title: Re: Unknown's thoughts on Wedge
Post by: [Unknown] on June 26th, 2011, 01:22 PM
Quote from Arantor on June 26th, 2011, 11:33 AM
In absence of anything else, the package manager means mod authors have to do direct edits to achieve things, rather than making use of facilities available. The main consequence of this is mods doing template edits which cause support issues because they then don't appear on some custom themes, or at least not the way they were intended. Adding to that, any theme that does do anything creative invariably fails, which is why so many themes are basically Curve knock-offs as opposed to anything more daring. (Yes, there were designers who do more daring things, but the vast bulk of the time the theme is just recoloured.)
Definitely.  And this is a large problem.  However, fixing it by accepting the poison (of no one doing anything interesting) seems like a bad solution to me.

It's kinda like if PHP had say, "ah, PHP 4 classes suck, so no one uses them.  Got it - let's just remove them in PHP 5."  Who knows what might have happened to PHP had they done that.  Would it have been the right move?  Honestly, can't say, I've heard good things about aspect based programming.
Quote from Arantor on June 26th, 2011, 11:33 AM
And while there are some huge mods out there (Nao and Dragooon's Aeva Media, SimpleDesk by me and a couple of others, plus the portal mods)
Well, a mod like my "wikilinks" mod could easily be made with plugins, as could the calendar and all of the other large, but very separate things you mention.  However, something like an "RPG/Shop" mod (a constant request, or at least used to be) is somewhat more specialized and can't always be done via hooks.  And there are also a ton of little things (small customizations I was paid to do in some cases, for example.)

You can build hooks for any feature, but too many hooks, and the system is confusing and the documentation is miles long.  I know early on we discussed hooking (in PHP 4) manually every function before/after, and there were a lot of concerns, including performance, which can matter a lot to people with huge forums like e.g. Ben_S.
Quote from Arantor on June 26th, 2011, 11:33 AM
they're still generally not that different, because he knows the reality of how many mods don't work on custom themes, and the support boards are full of it.
Well, sure.  Fixing that is a separate issue, though.  Overreacting to a problem by fixing it too many ways is a bad fallacy.  I call it the pendulum: if you look at anything, you'll see humans overreact throughout history.  Art history is a fairly good and clear example of this.  And look and computers: years ago it was all mainframes and terminals, then it went hard toward personal computers, and now it's the cloud and browsers.  You're crazy if you think browsers and terminals aren't, essentially, similar concepts.

That said, you'll always get some similarly.  That's just UX.  You can't build a completely different interface and expect people to understand it.  But you can build a snazzy one that builds on the concepts users know and have used elsewhere.
Quote from Arantor on June 26th, 2011, 11:33 AM
The lack of premium ecosystem for SMF also tells me there's a problem.
Sure.  In part, this is probably because building package servers is just plain not documented.  I was completely expecting to see something like the dag rpm repo happen, and never wanted to manage mods to the scale SMF ended up doing.
Quote from Arantor on June 26th, 2011, 11:33 AM
As for mods, the situation there is marginally healthier, indicating that people generally would rather have new features than themes (at least, there is more effort put into mods than there is in themes, in general)
I dunno, having looked around a bit on occasion to help people, I found it very fragmented.  I agree that SMF doesn't have an effective set of themes or mods.
Quote from Arantor on June 26th, 2011, 11:33 AM
For example, just glance through the last submitted mods to the mod site:
* adding a user's birthday to their profile summary (in addition to the date which is there)
* specifying an alternative email address for outgoing mail, so that the admin's email isn't used for notifications
* a bugfix for the IE8 jumping text box problem, because obviously that couldn't have been added to 1.1.14/1.1.15 or similar
* two different mods for adding the Google +1 button, one for per-topic, one for per-post
* a nice FAQ mod
* a mod to replace the stats area at the bottom of the board index with a jQuery-based tab solution (which means adding jQuery, and will fail on any other theme/mod that already added jQuery)
* a mod to add several symbols as editor buttons (like 1/2, 1/4)
* putting the page number in the title of the page
In order:

1. I don't see why this shouldn't be a "mod", if you will, just one that applies equally to all themes (if the theme has a facility for showing that type of user information.)  This is the sort of problem I tried to fix with TOX-G.
2. This seems like a good candidate for a core feature.  Ideally, it should be built to that standard (I'd always wanted to see features "baked" as mods before going into the core, not sure if that ever happened.)
3. Bugfix mods make sense IMHO.  Easy to remove and then install the official update later.  Hard for hooks to do this.
4. See #1.
5. This definitely seems like hook territory.  I assume it's got its own area and doesn't touch other sections.
6. This is a harder problem, but if it uses jQuery.noConflict it shouldn't cause issues even if there's a separate version of jQuery on the page.  That said, a consistent js framework is a good idea.
7. Sounds like hook territory.
8. Sounds like a fairly basic mod that has no theme problems.
Quote from Arantor on June 26th, 2011, 11:33 AM
Over the three months I was on the Cust team, reviewing mods, the vast bulk of what came in were certainly in the 'small tweaks' category.
See, here's where we get to the actual problem.

Now, at work we build iPhone apps.  Not the main thing we do, but one of the things.  We've made a handful of them.

Generally, we tell our clients: don't make an iPhone app.  Make a mobile HTML5 app.  They are better.  You don't have to deal with Apple's review processes.  They will slow you down, and possibly reject your app for even business reasons.  Don't fight that battle, just make an HTML5 app.

I think the reason for small tweaks being the most common kind of mod is that the whole review thing scares away mid-sized mods.  From your description, and what I've seen, there are "large" mods (which are really almost separate projects glued into the forum), and tiny mods.  Where's the mid-sized ones, which seem (or seemed in the past) abundant with vBulletin and phpBB, where you have to follow manual file editing instructions?  Why do those softwares have them, but not SMF?  Is it because SMF doesn't have enough hooks?

Caveat: I haven't really looked at vBulletin / phpBB mods in a while.  The company I work for will sometimes use them (or write custom ones for a client), but the developers decide that and I've never had to get involved.
Quote from Arantor on June 26th, 2011, 11:33 AM
That means if a particular mod and a particular theme don't play nicely, it's not related to the systemic issues currently in SMF and its environment, but it's that the theme does something the mod didn't expect, or vice versa - but it means that it can be dealt with on an individual basis. (Even WP has issues in this direction, I would note)
Everyone does.  But, supposing Wedge gets popular, I predict zip packages of files to either replace (ala osCommerce "mods"), or txt files/forum posts with manual editing instructions.  Hooks cannot possibly solve every thing a mod ought to be able to do, and if they are really enforced, you're only relegating to always being in the situation of large only-just-touching mods and tiny tweak mods.

And I find it ironic that a while ago someone was complaining that SMF banned bugfix mods, which clearly would not be possible with hooks (how does one fix, for example, a hook not firing when it should by way of hooks?)

/me"]takes a moment to say he did not intentionally hijack this topic.
-[Unknown]
Title: Re: Unknown's thoughts on Wedge
Post by: Dragooon on June 26th, 2011, 01:41 PM
Quote
/me"]takes a moment to say he did not intentionally hijack this topic.
Not a problem, the things you said are a good argument and worth a read.

Your iPhone app raised my eyebrow, mostly because I need to do something similar. Are the HTML5 apps made to be accessed by the browser, made using something like Sencha Touch, jQuery Mobile or jQTouch, or are they bundled into something like Phonegap to be treated like native apps?
Title: Re: Unknown's thoughts on Wedge
Post by: [Unknown] on June 26th, 2011, 02:09 PM
Quote from Dragooon on June 26th, 2011, 01:41 PM
Your iPhone app raised my eyebrow, mostly because I need to do something similar. Are the HTML5 apps made to be accessed by the browser, made using something like Sencha Touch, jQuery Mobile or jQTouch, or are they bundled into something like Phonegap to be treated like native apps?
Well, while I say we recommend against it, we've ended up building native apps in most cases.  Mostly because the client wants to be in the app store (but honestly, I personally am not really sure how much that's worth.)

The review process isn't horrible, and we actually like it internally - because they can give us good feedback.  But it's a danger for the client, because it means timeline and even scope can be affected by another entity.  And since that's what they're paying us for, that's why we need to make the recommendation.

Still, what this ends up doing is making the client pull back on their wants for the app.  Even larger clients, they phase it out a lot.  So the apps are smaller.

Apps on Facebook are a bit more "healthy" IMHO.  They come in a better gradient of sizes (even though they still are often cheesy.)  There's no enforced review process, but if you break the rules, you'll get reported.  In fact, they're much harsher than Apple, as Apple is more willing to work with you, and Facebook will toss you to the curb (and then maybe talk to you.)

Of course, neither platform is really "unhealthy" and Facebook has its own set of problems for sure.  And they both have some of the traditional problems of centralized application repos.  There are also a ton of other things that may be more responsible for their differences, not the least of which are things like screen real estate.

-[Unknown]
Title: Re: Unknown's thoughts on Wedge
Post by: Dragooon on June 26th, 2011, 02:13 PM
I agree with avoiding app store review process, mostly because I don't know how to make native apps(Never learned Objective C). Hence the reason I asked how you guys conceive HTML5 apps.
Title: Re: Unknown's thoughts on Wedge
Post by: Arantor on June 26th, 2011, 04:01 PM
No worries about derailing the topic. I think it's important we have this conversation, really! :) This is going to be a long reply, sorry!
Quote
Bugfix mods make sense IMHO.  Easy to remove and then install the official update later.  Hard for hooks to do this.
I'm not opposed to bugfix mods, per se. The fact that someone bothers to find a bug and post a fix is, on the whole, a good thing. I brought it up before, because it's one of the many infuriating things, that they can't seem to agree on a policy and actually stick to it.

In the SMF climate in particular, and in similar other climates, it indicates a few less desirable characteristics:
1. If your community is producing bug fix packages, we have to ask the question why aren't being made part of the core product?

Is it because your release schedule is far too long and people need the bugs fixed before you can/will get a new version out? Or is it because for some other reason, you're actually not going to incorporate that patch into the core?

In the case of the IE8 jumping text bug, having a mod submitted by one of the core dev team, rather than actually fixing it in trunk (considering that, in the timeframe of a matter of days, a patch to 1.1.x was actually released) - I cannot see any justification for *not* patching it.

2. It discourages people from upgrading. To me, an upgrade shouldn't just be about fixing problems, it should be an overall iteration on what was there before, so improvements (not necessarily new features, but improving existing ones) as well as fixing bugs.

I was amazed how many people weren't upgrading to RC5 because of a bug in RC3/4 and that they thought it was sufficient to use the small patch rather than actually doing the upgrade. Some of those people won't upgrade to final even though it has security-related changes.

I don't exactly want to encourage bugfix mods, which won't be possible with just hooks anyway, if nothing else it means that something else is wrong in the development process.
Quote
Definitely.  And this is a large problem.  However, fixing it by accepting the poison (of no one doing anything interesting) seems like a bad solution to me.
Oh, I'm not accepting the poison. Having spoken to as many people as I can on it, the one factor that seems to be causing it predominantly is mods, and that with having to 'dumb down' what they do because of kow-towing to mods, I went the other way. By making it so mods aren't able to touch templates, or at the very least, if they do (through TOX-G), they can do so non-invasively, that hurdle virtually ceases to be a hurdle.

I accept there are uses for direct file edits, but the more I think about it, the harder I find it to justify having direct file editing as a base feature.

The biggest problem with it is that it promotes a certain level of being lazy. For instance, there was a mod that set up a default avatar. The quickest route for most authors to implement that would be a template edit - with all the problems that brings, and far too few authors would have implemented it in loadMemberContext - though it did happen eventually.

Most of the mod authors are not strong programmers, and invariably look for the easiest route to implement something, which means template edits in the first line of attack, source edits in the second, and almost never taking advantage of the resources actually in SMF to pull some of it off.

It's only since RC4 and RC5 that we're starting to see authors actually take the time and effort to figure out smarter ways of implementing mods, i.e. using the expanded hooks now in SMF. (It's still broken, structurally, but it's a lot better than it was.)
Quote
It's kinda like if PHP had say, "ah, PHP 4 classes suck, so no one uses them.  Got it - let's just remove them in PHP 5."
Not to me, it's not. The comparative statement would be "ah, PHP 4 classes suck, so no one uses them. Why does no-one use them?" IOW, start by figuring out why no-one uses them, what is it they're after, what is it about the current behaviour that's broken?

When I asked myself the same question about the package manager, about what was broken, about what I wanted to see it capable of, I came up with the following:
* File permissions, and making files writable to PHP, is one of the single most asked questions on the support boards -> can we make mods that don't need to make the core files writable?
* Mods only working on certain versions, people asking whether mods will be updated -> does a mod expressly have to ask for a version, or can it attempt to determine if all the features it needs are available?
* Mods searching for code and not finding it, because the original code has been modified (either by a later version, wherein even the comments get modified sometimes, or by another mod) -> can we make mods that either don't need to modify the files, or can better manage to sort themselves out without having to trip over each other?
* Mods that need to modify templates -> why do they need to modify templates? Does it always have to be a template edit, or is it about the data the templates output? Can content be injected into a template in some other fashion?

The first one screams hooks. The second works better if hooks are available because you can even do detection then based on an add-on requiring certain hooks in order to work, and if they're not available, it won't work. The third just generally pushes away from editing files in general, and the last implies something like TOX-G.

It wasn't entirely a knee-jerk reaction as Nao could probably confirm; originally I planned to make the package manager be able to handle more, like registering hooks and so on from the get-go without having to dive into making an installer script, but the more we talked about it, the more I felt comfortable abandoning file edits in the base.
Quote
However, something like an "RPG/Shop" mod (a constant request, or at least used to be) is somewhat more specialized and can't always be done via hooks.
It does come up regularly enough. I'm not sure what you couldn't do with strategic insertion of hooks, it doesn't need to be insane.
Quote
Fixing that is a separate issue, though.  Overreacting to a problem by fixing it too many ways is a bad fallacy.
Or, as I tend to find, you're solving the wrong problem: the solution applied is right for a different problem to the one you thought you had. I don't honestly think the approach I'm pushing for is wrong. It has pros and it has cons, like everything else, and I believe that overall, the pros outweigh the cons more than in the current scenario.
Quote
Sure.  In part, this is probably because building package servers is just plain not documented.
It's not that hard to figure out. But premium sites can't use it because by definition everything in a package server has to be accessible by a simple GET and as far as I can tell, without any authentication handling.
Quote
I dunno, having looked around a bit on occasion to help people, I found it very fragmented.  I agree that SMF doesn't have an effective set of themes or mods.
To me that's a consequence of everything else: all the stuff we've talked about here, seems to me to discourage creators from creating new big stuff, and to a lesser degree, new little stuff too. I would note that all the big projects (the portals, Aeva, SimpleDesk) almost without exception go back 2+ years - SimpleDesk is the only really sizeable mod that turned up in 2010 from what I remember, though there are a handful of modestly sized mods (such as the WP user integration or SimpleSEF) from the same sort of timeframe. What I'm getting at is that the big stuff goes back and the smaller stuff is what's emerging - no doubt 2.0's slow dev cycle was a major factor in that too, with no-one really willing to contribute anything until 2.0 final came in, with all the retesting and updates required for each RC.

The thing most people seem to forget is that the bulk of mod authors aren't people just writing stuff to give away - they tend to write it for themselves and their site, then share.


Going back to the list of mods in particular:
Quote
1. I don't see why this shouldn't be a "mod", if you will, just one that applies equally to all themes (if the theme has a facility for showing that type of user information.)  This is the sort of problem I tried to fix with TOX-G.
It's a tweak, changing the existing behaviour. It's not really a 'new feature', is it?
Quote
2. This seems like a good candidate for a core feature.  Ideally, it should be built to that standard (I'd always wanted to see features "baked" as mods before going into the core, not sure if that ever happened.)
This is a particularly weird case. It is actually a core feature, just one that has no admin interface and is undocumented. All the mod package does is provide that interface in the admin panel. (It's been a core feature for years, too.)
Quote
3. Bugfix mods make sense IMHO.  Easy to remove and then install the official update later.  Hard for hooks to do this.
See above. If you have to accept bugfix mods, there needs to be a reason why they're not in the core, especially when they affect a lot of users.
Quote
4. See #1.
The Google +1 button is in between being a 'tweak' and being a new feature of sorts. And any such change, where it is per post, seems to me like it's tweaking the layout and presentation - and an ideal candidate for something like TOX-G, rather than having to modify any code.
Quote
5. This definitely seems like hook territory.  I assume it's got its own area and doesn't touch other sections.
Yes. It's even implemented actually using hooks, too.
Quote
6. This is a harder problem, but if it uses jQuery.noConflict it shouldn't cause issues even if there's a separate version of jQuery on the page.  That said, a consistent js framework is a good idea.
jQuery is a core feature in Wedge and is slated to be in SMF 2.1 too. But it's slightly awkward that there's no facility to figure out what JS is being included and whether you need to include it yourself. (This is possible with Wedge.)
Quote
7. Sounds like hook territory.
Or better IMO, make the editor buttons configurable to the admin, so if they want to add them, they can. But yes, this could be achieved with hooks (even in SMF) and I don't think it is.
Quote
8. Sounds like a fairly basic mod that has no theme problems.
Well, I'd personally debate that it should be a core feature rather than a mod.


I get the feeling that we're never going to entirely agree on this, but where we're coming from, I think we both feel justified in the stance we take - and are prepared to defend that if necessary. I don't feel uncomfortable with kicking out file edits off the bat, because if they're actually needed, the mod author who needs to use them can document them and deal with it.

The other thing is, a number of the popular SMF mods, I'm going to be writing equivalent (not necessarily replacement) versions of, and making them available, so I'm also making sure the system is capable of the things that I want it to be able to do; I'm not just designing this in some hypothetical vacuum of what it should or should not be able to do, I'm actively building it for my own use as much as anything else.
Quote
I think the reason for small tweaks being the most common kind of mod is that the whole review thing scares away mid-sized mods
I'm not sure it does, to be honest. I think it's more systemic than that. The mods that are big and scary (SP, TP, Aeva, SimpleDesk etc.) all have one common thing: the actual code editing SMF is relatively small, and everything else is in their own files. Meanwhile the mods that are small are just pure code edits (except for the few that are now hook-only).

You mention phpBB and vBulletin... I thought phpBB mods were still, basically, find/replace instructions. (A cursory examination of the phpBB site seems to bear this out but it is strictly a glance rather than a proper study)

As for vB, I have no idea, never used it as an admin, never particularly wanted to.

But I've seen even large-scale phpBB mods done, well, as lists of file editing, which says to me either there aren't hooks, or they're not really in use much.

I'm not sure why SMF doesn't have much in the mid-range, but I'm fairly sure it's not the review process. Small mods are fine with the find/replace approach, but larger mods invariably tend to need more changes and after a point it becomes too much of a pain to maintain with all the changes, and/or they start outgrowing the confines of doing it like that and start needing their own files.

That all said, I'm willing to bet that part of the problem is simply that most mods are contributed by people in their spare time, without any interest or desire in writing big and complex mods - they wrote things for their own site(s) and leave it at that. They don't need or want big and complex mods, so they don't write them. Which also comes back to the lack of premium contributions - what I've seen tends to be that paid mods come into a market first then free competition springs up in response, but SMF didn't really go over that tipping point.
Quote
Hooks cannot possibly solve every thing a mod ought to be able to do, and if they are really enforced, you're only relegating to always being in the situation of large only-just-touching mods and tiny tweak mods.
I agree, to a point. The thing is, apart from the fact that it doesn't seem to have hurt MyBB or WordPress (and especially WordPress), I'm not convinced it will restrict to large or tiny mods. As I've proved before now, all kinds of curious things can be done with some ingenuity even in the current SMF environment (like, for instance, adding multiple helpdesk departments as boards to the board index, but using a custom icon, custom description and link and so on - without a single template edit, even if it is woefully ugly because the structure just doesn't support it normally)

There is one overriding factor here. SMF and some hooks and a hook manager won't be enough. It won't solve the problem at all to do that.

For example, permissions. It's easy enough to add new permissions provided all you want to do is add new permissions for per-board profiles or to a group generally, but anything else, you have to implement it yourself from scratch. Aeva, SimpleDesk, Project Tools and others have had to do this, because the existing system only lets you expand it in one dimension when it needs to be able to provide for two - even if it only barely uses the second dimension itself.

Or, the board index as I mentioned above - there's no reason why there couldn't be an expansion of the board index, not only to be able to understand the board structure and hierarchy but also to have some awareness of the *type* of board, so that new things can make use of it if they want.

That's really what we have to do: just expanding hooks on its own won't be enough. We have to make everything else be more open to extension too, and upon doing that, almost anything should be possible.
Title: Re: Unknown's thoughts on Wedge
Post by: Dragooon on June 26th, 2011, 08:46 PM
Quote
To me it seems Wedge has already been laid out with that lesser possibilities for me as a designer, while SMF is still "full on"...although its focus on CSS-only themes takes away the focus on getting mods out of themes. But at least you CAN still change any template, luckily. I do remember Nao mentioned that it can be done in Wedge too, so its not all bad - but focusing on stylings sends a powerful signal out to any starting designer for Wedge.
Wedge's theme system is only beyond SMF's, it doesn't remove any of the previous possibilities but has enhanced capability for additional css variations.
Quote
But I also see WHY Nao/Arantor wants more features in - more powerful, central developing point etc. I think thats a slightly wrong turn though. Take Yourasoft, where a core was to replace SMF, with its forum as a module only(allowing others to also make other forum modules). It was from day one agreed that things should/could have alternatives.
Personally, I think it is a more positive turn. Not only does it ensure a system that is powerful and well integrated down to the core, it adds more capabilities for a small time modder to extend upon. It may discourage alternatives, but it doesn't necessarily prevent them. Instead, it helps to improve the existing system with multiple people pouring in.
Title: Re: Unknown's thoughts on Wedge
Post by: Nao on June 26th, 2011, 09:03 PM
We aren't focusing on Stylings. I just offer them as an easy alternative for non modders who want to have different themes for their users without making it a hassle to maintain.
Title: Re: Unknown's thoughts on Wedge
Post by: Arantor on June 26th, 2011, 11:24 PM
Yes, there are mods that modify the moderation centre, or at least affect it in some way. It's not really a good example though.

Thing is, you mention about mods doing the same as existing... Yet why are there only two gallery mods for SMF? The argument is the same, really.
Title: Re: Unknown's thoughts on Wedge
Post by: [Unknown] on June 26th, 2011, 11:30 PM
WARNING: Haven't red Bloc's reply or Arantor's follow up yet.  However they are quoting other things I haven't read either, so I'm a bit confused.  I'm going to back up and re-read the whole topic, but I figured this reply still probably stands.
Quote from Arantor on June 26th, 2011, 04:01 PM
1. If your community is producing bug fix packages, we have to ask the question why aren't being made part of the core product?
The kernel has patch sets.  PHP has them too - even though PHP has defined extensions, which are more common.

Open source is all about the community producing bug fix packages, and having a way to "bake" a fix before it going into the core is a very good idea.  Mozilla and other vendors do a lot to offer and maintain several concurrent branches to manage this - but since PHP is source based, the package manager is a much more natural method.

Certainly if the bugfixes are long lived, it's a problem.  When I had my bug fix mods, they only lived for maybe < 1 week until YaBB SE 1.5.1, and then I think 1.5.2 came out.  But people loved them nonetheless.

FWIW, one of the things I would do differently now - before, I would often post on support like this:

Open XYZ.php, search for:
Code: [Select]
abc

Replace with / Add before / Add after:
Code: [Select]
xyz

[[How do I modify files?]]

Whereas nowadays I would probably do this instead:

$ svn diff -c 1234 | smf_diff2modxml | smf_package unknownbrackets:fix_1234 "Fix for XYZ" --versions=2.0 > fix_1234.zip

And just give that to them, with e.g. [[How do I use a bugfix package?]] which would note their removal during an upgrade.
Quote from Arantor on June 26th, 2011, 04:01 PM
I cannot see any justification for *not* patching it.
Sure.  But release schedules happen, and frankly unless it's high-priority, I wouldn't release a new version within 1 week of the other, so as to collect other bugfixes.  Maybe, if some are really hard to fix, even 2 weeks.  While people like software that works, they hate having to upgrade over and over, and there's a danger they will just skip the upgrades and wait a while if they're too frequent.
Quote from Arantor on June 26th, 2011, 04:01 PM
2. It discourages people from upgrading. To me, an upgrade shouldn't just be about fixing problems, it should be an overall iteration on what was there before, so improvements (not necessarily new features, but improving existing ones) as well as fixing bugs.
Realistically, large upgrades are hard, especially for some deployments, and also dangerous just because of surface area.

Look at for example, Gentoo or CentOS or anyone.  They have slightly older versions of PHP/MySQL/OpenSSL/etc.  But these all have backported fixes.  Now, obviously, this is an annoyance... I'd rather everyone used the latest PHP.  But there are stability questions, and a whole slew of reasons why people prefer to use backported fixes.

A package manager isn't going to change this (one way or another), and a policy against the concept may stifle commercial adoption.
Quote from Arantor on June 26th, 2011, 04:01 PM
Most of the mod authors are not strong programmers, and invariably look for the easiest route to implement something, which means template edits in the first line of attack, source edits in the second, and almost never taking advantage of the resources actually in SMF to pull some of it off.
Sure.  My company also, for example, does customized Wordpress installs.  Generally, we write these as plugins and template changes, which solves the problem most of the time, sure.  But there have been times when we've done file edits, which certainly causes upgrade problems, and can even be hard to track since there's no management on top.  Too often, these installs get left un-upgraded because the client doesn't want to pay for the effort to upgrade them, even when it needs to be done.

Wordpress also does more to "freeze" the template interface, which is a whole separate conversation, and probably another factor to why complex themes don't generally exist.

And the default avatar - implementing this using TOX-G seems natural to me.  Assume for a moment:

Code: [Select]
Themes/default/basic.tox:
<tpl:template name="we:avatar" requires="url">
   <tpl:if test="!empty({$url})"><img src="{$url}" alt="" /></tpl:if>
</tpl:template>

Themes/cooltheme/basic.tox:
<tpl:template name="we:avatar" requires="url">
   <tpl:if test="!empty({$url})"><div class="avatar-box"><img src="{$url}" alt="" /><div></tpl:if>
</tpl:template>

Packages/defaultavatar/overlay.tox:
<tpl:alter match="we:avatar" position="before">
   <tpl:if test="empty({$url})">
      <tpl:set var="{$url}" value="{$settings.defaultavatar.url}" />
   </tpl:if>
</tpl:alter>

This seems natural to me.  It also means no problems like, say, accidentally setting someone's avatar to the default url when they edit their profile.  To avoid potential problems, this is probably how I would approach such a mod.

Making the right way easy is definitely a good thing.  Perhaps show a message when the mod contains file changes:
Quote
Warning: This package modifies core functionality of Wedge, and may need to be uninstalled prior to an upgrade.

When you upgrade, the package manager will automatically uninstall this package for you if it conflicts, and it may need to be reinstalled or even rewritten at that time.
It's good to warn people not to do things they probably don't want to do.  I still think there is an established use case for it, just as long as people are careful.
Quote from Arantor on June 26th, 2011, 04:01 PM
* File permissions, and making files writable to PHP, is one of the single most asked questions on the support boards -> can we make mods that don't need to make the core files writable?
I'm not sure this is a hard problem.  Yes, the package manager still has bugs in this area, and since writing it I've changed my mind on some things.  However, this goes back to another gripe I have... why isn't the webinstaller being pushed more?

Also, automatically restoring the permissions is something it should do, I thought it did.  If it doesn't, I just consider that a bug.
Quote from Arantor on June 26th, 2011, 04:01 PM
* Mods only working on certain versions, people asking whether mods will be updated -> does a mod expressly have to ask for a version, or can it attempt to determine if all the features it needs are available?
Yes, they do.  Look at extensions for Firefox, which don't do any "core edits."  Chrome has this problem less, but also the extensions can do a lot less.  And, for example, the latest "Page Speed" extension is broken in Chrome, and the latest Closure Inspector is broken in Firefox.  Both of these use plugin models.
Quote from Arantor on June 26th, 2011, 04:01 PM
* Mods searching for code and not finding it, because the original code has been modified (either by a later version, wherein even the comments get modified sometimes, or by another mod) -> can we make mods that either don't need to modify the files, or can better manage to sort themselves out without having to trip over each other?
Making it less likely is great.  Probably 80% of mods should never modify a file, and that could really help solve this problem.  I'd guess that the places where mods normally conflict is e.g. mod settings and such, places that are clearly hook fodder.
Quote from Arantor on June 26th, 2011, 04:01 PM
* Mods that need to modify templates -> why do they need to modify templates? Does it always have to be a template edit, or is it about the data the templates output? Can content be injected into a template in some other fashion?
Well, even in the worst case where they do modify a template, if things are more reused and base templates are inherited by themes and used, it's much less of a problem.

In general, I just feel like you are over-solving the problem.  Even if mods still just edited themes (without using TOX-G overlays, which although I made them as simple as possible, still take some thinking to understand), a system of inheritance and a larger set of templates would solve a lot of these problems alone.
Quote from Arantor on June 26th, 2011, 04:01 PM
making an installer script, but the more we talked about it, the more I felt comfortable abandoning file edits in the base.
Well, frankly, I see these installer scripts as way too complicated.  I think it's ironic that adding a core upgrade (to the upgrade SQL) seems to be easier and simpler than adding a table in a mod.
Quote from Arantor on June 26th, 2011, 04:01 PM
It does come up regularly enough. I'm not sure what you couldn't do with strategic insertion of hooks, it doesn't need to be insane.
Yes, but you're building a solution around a single problem, not the whole set of potential problems.  Given a specific mod, anyone could add the necessary hooks for it - but that's an unending problem.
Quote from Arantor on June 26th, 2011, 04:01 PM
It's not that hard to figure out. But premium sites can't use it because by definition everything in a package server has to be accessible by a simple GET and as far as I can tell, without any authentication handling.
If they were used more, there would be more feature requests, and this could be handled.
Quote from Arantor on June 26th, 2011, 04:01 PM
The thing most people seem to forget is that the bulk of mod authors aren't people just writing stuff to give away - they tend to write it for themselves and their site, then share.
I don't forget that, it's the same with everything.  Even the bugfix mods I wrote were really to manage them on my own site, and also share.  Not just to be a philanthropist.
Quote from Arantor on June 26th, 2011, 04:01 PM
Or better IMO, make the editor buttons configurable to the admin, so if they want to add them, they can. But yes, this could be achieved with hooks (even in SMF) and I don't think it is.
SMF's admin is confusing and overly complicated.  I'd rather see the complicated things (including custom BBC and editor buttons and such) be left as mods with just configurable hooks.  This is essentially what Wordpress does AFAICT and it's a win IMHO.
Quote from Arantor on June 26th, 2011, 04:01 PM
Well, I'd personally debate that it should be a core feature rather than a mod.
Why?  You want to add another checkbox somewhere for whether to show the page number in the title?  I'm sure some SEO people would go nuts about it, so it has to turn off.  I don't see it as having a huge number of people who want it either.
Quote from Arantor on June 26th, 2011, 04:01 PM
But I've seen even large-scale phpBB mods done, well, as lists of file editing, which says to me either there aren't hooks, or they're not really in use much.
And yet they are popular, and don't have some of the systemic problems SMF's mods have.  I think this points to file edits not necessarily being the culprit as you suspect, because if they were they'd affect other software equally.
Quote from Arantor on June 26th, 2011, 04:01 PM
That all said, I'm willing to bet that part of the problem is simply that most mods are contributed by people in their spare time, without any interest or desire in writing big and complex mods
Why does this not affect other software?  Are you proposing a different (more selfish) audience uses SMF than other forums?

I agree paid mods are a problem.  While SMF hasn't made those easy, I'm not sure how it has made them hard.  I think there's a lot to that problem as well.
Quote from Arantor on June 26th, 2011, 04:01 PM
I agree, to a point. The thing is, apart from the fact that it doesn't seem to have hurt MyBB or WordPress (and especially WordPress)
I think hooks are used very heavily in Wordpress.  Yet memory (and a cursory Google search) shows that patches and file edits are still used in their themes and plugins, often enough.  I know I've installed off-the-shelf themes for friends and had to do file edits manually.
Quote from Arantor on June 26th, 2011, 04:01 PM
I'm not convinced it will restrict to large or tiny mods.
I'm not saying it will, I'm just saying people will go to manual file edits.  I personally think (and have heard from many people) that SMF's managing these for you is still a good idea.
Quote from Arantor on June 26th, 2011, 04:01 PM
That's really what we have to do: just expanding hooks on its own won't be enough. We have to make everything else be more open to extension too, and upon doing that, almost anything should be possible.
Certainly.  That's a separate problem and a good problem to solve.
Quote from Nao/Gilles on June 26th, 2011, 09:03 PM
We aren't focusing on Stylings. I just offer them as an easy alternative for non modders who want to have different themes for their users without making it a hassle to maintain.
Okay.

-[Unknown]
Title: Re: Unknown's thoughts on Wedge
Post by: [Unknown] on June 26th, 2011, 11:47 PM
Quote from Bloc on June 26th, 2011, 07:51 PM
but they will want more the things they can't imagine yet.
Absolutely.  I'm not satisfied with providing hooks only, because of this very reason.  Even if it means only one super cool not-yet-imagined theme or mod, I'd prefer to have the door wide open for it.
Quote from Bloc on June 26th, 2011, 07:51 PM
As I also mentioned on Blocweb, adding too many features in Wedge makes creating alternatives less desirable for others. Why create a gallery when theres one built-in?
Exactly, I think I said this about the calendar somewhere else.
Quote from Bloc on June 26th, 2011, 07:51 PM
Take Yourasoft, where a core was to replace SMF, with its forum as a module only(allowing others to also make other forum modules). It was from day one agreed that things should/could have alternatives.
Ultimately, it needs to be done in baby steps or it will never happen.
Quote from Bloc on June 26th, 2011, 10:42 PM
In contrast, are there any mods that replace the moderating center in SMF2? In SMF11 there could have been more alternatives(was there more? I can't remember) but in SMF2 theres no reason to now. And that moderating center isn't a solution to all moderating needs..
Didn't 1.1 have some moderation center?  I never really used/liked/understood it to be fully honest.

The problem with features like that is they "bake" a specific idea into people's minds, such that it's harder to solve different ones.

For example, I use a callback-based HTTP system for some of my stuff.  This means, I do something like this:

Code: [Select]
$http->queue_get($url, $headers, $callback, $curried_params);

$http->queue_get($url, $headers, $callback, $curried_params);
$http->queue_get($url, $headers, $callback, $curried_params);
$http->queue_get($url, $headers, $callback, $curried_params);

$http->process();

The library itself multiplexes the sockets and executes the HTTP requests simultaneously.  It makes a number of requests, so these complete in a fraction of the time they would traditionally.

So, then, why is it that this model is so rare in PHP?  Well, since I hate curl, I'll blame it.  Since curl is an extension most people have in PHP, most people end up using it, not even the built in HTTP functionality of PHP.  Yes, it has a lot of features and is stable and built out well... no, it doesn't have a good security track-record in PHP nor a great PHP interface.

I'm the type of person who likes alternatives, and likes to write them.  Just because something exists doesn't mean it's the best.  But it's hard to approach something that has an integrated thing, and replace it.  For upgrade reasons, I would be more tempted to modify the existing feature, than to remove it and add my own.
Quote from Bloc on June 26th, 2011, 10:42 PM
if its part of what you set out to achieve then that won't matter lol.
Heh, don't apologize for having opinions.  Even if they aren't a right fit for Wedge's audience or goals, I think input from many is always a good thing.

-[Unknown]
Title: Re: Unknown's thoughts on Wedge
Post by: Dragooon on June 26th, 2011, 11:52 PM
Quote from Bloc on June 26th, 2011, 10:42 PM
Quote from Dragooon on June 26th, 2011, 08:46 PM
Quote
To me it seems Wedge has already been laid out with that lesser possibilities for me as a designer, while SMF is still "full on"...although its focus on CSS-only themes takes away the focus on getting mods out of themes. But at least you CAN still change any template, luckily. I do remember Nao mentioned that it can be done in Wedge too, so its not all bad - but focusing on stylings sends a powerful signal out to any starting designer for Wedge.
Wedge's theme system is only beyond SMF's, it doesn't remove any of the previous possibilities but has enhanced capability for additional css variations.
Quote
But I also see WHY Nao/Arantor wants more features in - more powerful, central developing point etc. I think thats a slightly wrong turn though. Take Yourasoft, where a core was to replace SMF, with its forum as a module only(allowing others to also make other forum modules). It was from day one agreed that things should/could have alternatives.
Personally, I think it is a more positive turn. Not only does it ensure a system that is powerful and well integrated down to the core, it adds more capabilities for a small time modder to extend upon. It may discourage alternatives, but it doesn't necessarily prevent them. Instead, it helps to improve the existing system with multiple people pouring in.
Yes, its good..but honestly, why would anyone create a mod that does what Aeva does then? In contrast, are there any mods that replace the moderating center in SMF2? In SMF11 there could have been more alternatives(was there more? I can't remember) but in SMF2 theres no reason to now. And that moderating center isn't a solution to all moderating needs..

I am not saying to ALWAYS have alternatives..the quality will maybe be worse sometimes, but with Aeva as built-in rather than a plugin, you will not see any evovlement in that area other than what you do yourself. It depends on how you look at it if thats a good thing or not.
Currently there are only 2 gallery mods for SMF, Aeva and SG(3 of you count SGL and SGP separately), and I created SMG(Base of Aeva) after SGP had been out for over 2 years(And it had dominated that time). Same's the case with TinyPortal, it had been out for a long time before an alternative game, simply because it dominated for a long time. Now there are 5 portal, which do the same thing in more or less the same way. So in all honestly, having a feature in core won't make that much of a difference provided there is someone who is willing to do that kind of effort to match up to it. This is emphasized by the fact that Nao spent 2 weeks straight on SGP before I released SMG, only because he didn't want to create one from scratch and had SGP as a base . Instead, most will try and improve what is in the core rather than making an alternative to it. This way a new kind of variety will be created. Plus we always got integration to 3rd party systems.
Title: Re: Unknown's thoughts on Wedge
Post by: Arantor on June 26th, 2011, 11:59 PM
Unfortunately right this moment I don't have time to reply to everything but the stuff I see as really important I'll deal with right now and tackle everything else shortly.
Quote
Yes, they do.  Look at extensions for Firefox, which don't do any "core edits."  Chrome has this problem less, but also the extensions can do a lot less.  And, for example, the latest "Page Speed" extension is broken in Chrome, and the latest Closure Inspector is broken in Firefox.  Both of these use plugin models.
And that's because they still depend on version checking. My proposed method explicitly does NOT check for Wedge version.
Quote
It's good to warn people not to do things they probably don't want to do.  I still think there is an established use case for it, just as long as people are careful.
That's one of my points: I don't see people being careful. I see it as enabling the shortest route to a problem, which leads to all the things I mentioned before.
Quote
I'm not saying it will, I'm just saying people will go to manual file edits.  I personally think (and have heard from many people) that SMF's managing these for you is still a good idea.
Following on from that: I'm not against file edits per se, for all the reasons you've mentioned. I just don't want to leave them in because people will continue using practices they learned in SMF rather than learning new habits, like using hooks where there are hooks available for things.
Quote
Why does this not affect other software?  Are you proposing a different (more selfish) audience uses SMF than other forums?
It probably does, I haven't spent any time in their ecosystems. But given the mods submitted, the relative skill level of the coders and so on, the majority are certainly not contributed by veteran coders.
Title: Re: Unknown's thoughts on Wedge
Post by: [Unknown] on June 27th, 2011, 12:19 AM
Quote from Arantor on June 26th, 2011, 11:59 PM
And that's because they still depend on version checking. My proposed method explicitly does NOT check for Wedge version.
Chrome doesn't do version checking.  Yet the problem still exists.
Quote from Arantor on June 26th, 2011, 11:59 PM
It probably does, I haven't spent any time in their ecosystems. But given the mods submitted, the relative skill level of the coders and so on, the majority are certainly not contributed by veteran coders.
Indeed, this is always the case.  But other forum softwares have a richer gradient of mods.  If they use file edits too, that can't be the solution to make SMF/Wedge have an ecosystem more like theirs.

Joomla also has patches.  For example, this one:

http://www.joomlatwork.com/products/free-downloads/seo-patch-joomla-15.html

Do you suppose this is a better alternative to automated file edits?  Note that they take the path of least resistance: a zip file containing the modified files, to overwrite in your installation.

I'm suggesting that you will only make this type of modification more popular (in the case that mods exist that do more than tiny things at all, so hopefully) which seems like a worse disease than the original injury.

-[Unknown]
Title: Re: Unknown's thoughts on Wedge
Post by: [Unknown] on June 27th, 2011, 04:19 AM
FWIW, I recalled I'd had a conversation about this sort of thing a while back re: SMF.  A quick email search later, here's a copy/paste:
Quote from "[Unknown
, 2005-02-17"]
Actually, I've messed around with doing things like this several times.  Some of the solutions I've come up with have involved reading files from a directory, serailizing the information gained from them together, and writing it to a cache (whether database, file, or otherwise.)  That may seem roudabout, but I really can't like an idea if I know it's going to be slow and less-than scalable.

Using this system, a registry in the database isn't technically needed, although it could be useful.  The gain of not having it in the database is that plugins can be loaded before the connection is made: and this would allow, as an example, plugins to mean other-database support.

But, obviously, a table has clear benefits (and makes it notably easier to upgrade plugins, which is something a lot of systems ignore!)  The downside is that all of this information is going to be needed all the time, so everything is going to have to be loaded from the table (not just some.)

...

It would also mean essentially abstracting every internal function call.  Imagine:

processFunction('db_query', 'load_settings', array("
   SELECT variable, value
   FROM {$db_prefix}settings", __FILE__, __LINE__));

Again, macros and such would make this better.  Or even just an event system:

fire_event('loaded_settings');

Although you're right, the major problem there is that the function can't mess with the local scope.  That's what I like about macros - I wish we could do this:

.. snip longish example that closures basically finally allow ...

And these could be automatically inlined during compilation, and then possibly optimized out if possible.

Anyway, I do agree that extensibility is one of the main things SMF needs to gain... I guess I'm just really hard-nosed about the common methods of doing it :P.
This was actually in reply to Joseph Fung.  I'd copy his message but I'd want to get permission first.

It's not like we thought it wasn't necessary, but there were license issues and it just got bogged down.  'Course we really liked to play around, e.g. smflib.  I had been seriously considering creating a macro language for PHP and inlining it on release, although it was probably a bad idea.

-[Unknown]
Title: Re: Unknown's thoughts on Wedge
Post by: groundup on June 27th, 2011, 03:25 PM
I need to bookmark this for later read.
Title: Re: Unknown's thoughts on Wedge
Post by: Dragooon on June 27th, 2011, 04:37 PM
While removing file edits in itself is a step backward in terms of freedom one provides to mod authors, I can see Arantor's point. I am personally with keeping file edits as everything is not always possible with hooks, but if we do keep file edits then most people will resort to directly editing files. But at the same time I do not completely like the idea of removing file edits. Perhaps if there was something in between? Like classifying mods, file edit mods are class B and totally hooked mods are class A. The reason being that I cannot see everything being done with file edits, I need file edits for WePortal which is more or less the first mod for Wedge(Unless someone beats me to it). So please keep file edits, but instead frown them upon.
Title: Re: Unknown's thoughts on Wedge
Post by: Arantor on June 27th, 2011, 05:22 PM
We can frown upon it all we like, the fact is if it's available in the core, it will be used because so many people are used to doing it that way. It will encourage people to port from SMF, including all their bad habits, and it will encourage them to do that rather than use all the better methods that we could devise.

In which case, we might as well say fuck it and leave it how it is because that's obviously so much better.
Title: Re: Unknown's thoughts on Wedge
Post by: snoopy-virtual on June 27th, 2011, 07:44 PM
My personal opinion is that if it can be done using only hooks I would prefer it.

I don't know how many hundreds of hours I have lost asking questions like "OK, let me see what Theme you are using to see why you are having problems with this mod" or "Give me the list of the mods you have in your forum to see if I can find out which one is interfering with that one", etc etc. (Of course you don't just ask those questions. After they answer you need to dig inside to find the problem and sometimes you find it in a minute and sometimes you need hours to find it).

Or the amount of hours lost updating mods every time there is a new version in SMF (not only my mods but also the mods I use in my forums that have nobody updating them just now) or helping people with less experience to update their forums.

I know for me is not going to be easy to learn how to port my SMF mods to Wedge using only hooks, but I know 3 things:

1.- If Arantor says it's possible to do it I believe it. I trust his opinion there.

2.- Learning how to do it is going to be fun (at least for me).

3.- Once I manage to do one (even if it takes me a lot of work at the beginning) I won't need to worry any more about that mod. No more updates every time there is a new version in the core. No more worries about any other plugins interfering with it or changing my plugins because they are not compatible with a particular Theme etc.
Quote from Dragooon on June 27th, 2011, 04:37 PM
The reason being that I cannot see everything being done with file edits, I need file edits for WePortal which is more or less the first mod for Wedge(Unless someone beats me to it). So please keep file edits, but instead frown them upon.
What about letting Arantor take a wee look at your code to see if he can find out how to do it using only hooks? If he has managed to do Simple Desk 2.0 (a really big mod) using only hooks he may have some ideas that could help you out there.

I could think on a few more solutions, but maybe would be better to talk about them inside the proper place in private.
Title: Re: Unknown's thoughts on Wedge
Post by: Arantor on June 28th, 2011, 01:18 AM
Quote
If he has managed to do Simple Desk 2.0 (a really big mod) using only hooks he may have some ideas that could help you out there.
SD 2.0 still requires multiple file edits (which I swear I said several times) because the hooks don't exist in SMF that would be needed to make it work, and in one case the hook exists but it doesn't support the operations required by SimpleDesk.

But since it's become increasingly clear that I'm barking up another wrong tree, I might as well revert what I've done and go with my first plan of enhancing what's there and praying to $deity that my fears are baseless, except I know full well I'm right there.

Anyway. I have more alcohol to drink right now, a hangover for the morning, followed by a 200 mile road trip, just so I can go to a family funeral tomorrow, I'm looking forward to setting out in... a little over 5 hours yay. Have fun discussing it in my absence, but FWIW I already reverted the changes I made, so whatever I do when I come back will be fresh rather than deluding myself that I could fix all the problems I found with SMF, bring on all the worst problems SMF has without much of the solutions I'd hoped and believed could have been solved.

(See, Unknown's someone I look up to and when he says in not so many words that he thinks I'm working off broken logic, I tend to agree with him. Then I remember that he's younger than me and still managed to achieve so much more than I have so far, and I quietly begin to question myself. I hear my beer calling.)
Title: Re: Unknown's thoughts on Wedge
Post by: snoopy-virtual on June 28th, 2011, 02:53 AM
Quote
SD 2.0 still requires multiple file edits (which I swear I said several times)
Yes of course, the SMF version. But I was talking about Simple Desk for Wedge. And don't tell me that's not done yet, because I am sure it is. Maybe not physically, but it's already in your head. And I bet that version hasn't got any file edits at all.

Maybe I'm wrong but I suppose, all the time you were creating SD 2.0 for SMF, you were thinking how you could have done every small detail for the Wedge version and, all the work you have done lately here, you have done it taking into consideration all those things you were thinking while creating SD for SMF. Don't remember exactly where I have seen it, but I am sure you have said something very similar a couple of times here.
Quote
But since it's become increasingly clear that I'm barking up another wrong tree, I might as well revert what I've done and go with my first plan of enhancing what's there and praying to $deity that my fears are baseless, except I know full well I'm right there.
I think if you do that it will be a wrong move. I think the right decision was when you decided to forget completely file edits and do everything with hooks. Of course it's not up to me at all to decide what you are going to do. It's up to you.
Title: Re: Unknown's thoughts on Wedge
Post by: Eros on June 28th, 2011, 04:27 AM
I figured I'd toss my two cents in, as someone who more or less, has always intended to go around SMF (except for bridging authentication) as much as possible. That, and I'm not a web developer, so it is easier for me to work that way and fix my own mistakes without affecting an adequate solution. I also have a tendency to react without thinking things through simply because of some of the things I've seen in my limited experience .

File edits are a pain in the ass to maintain between versions and so are hooks. I don't think either is going to change developer behavior sufficiently to be worth picking one or the other solely for that reason.

If you provide Hooks, you need to also provide File Edits to avoid Unknown's concern of people causing trouble that way.

If the real, and only concern, is the size and quality of mods...you are probably better off coming up with positive incentives to create certain types, and a certain quality, of mods rather than relying on the method of modifying Wedge to do it for you. I've got no good idea how to go about that simply because I've never tried to foster a developer community around a project outside of a situation where everyone is being paid to care about said project.
Title: Re: Unknown's thoughts on Wedge
Post by: [Unknown] on June 28th, 2011, 05:25 AM
Quote from Arantor on June 28th, 2011, 01:18 AM
Anyway. I have more alcohol to drink right now, a hangover for the morning, followed by a 200 mile road trip, just so I can go to a family funeral tomorrow
Dude, don't worry about this.  Take care of that first.  This is just a discussion between peers.

Sorry to hear you've had drama.  Hope things are okay.
Quote from Arantor on June 28th, 2011, 01:18 AM
But since it's become increasingly clear that I'm barking up another wrong tree, I might as well revert what I've done and go with my first plan of enhancing what's there and praying to $deity that my fears are baseless, except I know full well I'm right there.
I tend to have strong opinions when it comes to code.  I have concerns about your approach, but that doesn't mean it's wrong.  I'm just some guy.

I agree with your concern about porting of mods.  IMHO, a way to solve that is to disable it for now, or except for specifically Wedge update packages perhaps.  Then table re-enabling it for when necessary.  Worst case, people could write a mod to add it back in, but that'd be possible anyway.  And if it turns out you're right, remove it fully, just not right away.
Quote from Arantor on June 28th, 2011, 01:18 AM
(See, Unknown's someone I look up to and when he says in not so many words that he thinks I'm working off broken logic, I tend to agree with him. Then I remember that he's younger than me and still managed to achieve so much more than I have so far, and I quietly begin to question myself. I hear my beer calling.)
For every gainful thing I have, there's a loss as well.  A discussion between peers should be based on the merits of their points; experience and even accomplishments are only resources one can draw from to build their points - but they don't make the argument alone.

-[Unknown]
Title: Re: Unknown's thoughts on Wedge
Post by: Nao on June 28th, 2011, 07:49 AM
How old are you, Unknown?
If you're younger than Pete is, does that mean you were one of those Dragooon-like wizkids back when you started SMF?

I hate those fucking wizkids, they always end up being faster and better than me :niark:
Title: Re: Unknown's thoughts on Wedge
Post by: [Unknown] on June 28th, 2011, 07:57 AM
I'm 25, so I guess I was about 17 when I started working on SMF.  Certainly have learned a few things since then.

Dunno about whizzkid, essentially I spent the couple years after high school working on SMF before I got a job.  It's much easier to get a lot of things done when you don't have other obligations etc. yet.  More a function of circumstance.

-[Unknown]
Title: Re: Unknown's thoughts on Wedge
Post by: Nao on June 28th, 2011, 08:29 AM
Always thought you'd be my age. Youngsters usually don't value privacy. :P

Then again I've had several lives before the current one. I'm younger than you when it comes to php.
Title: Re: Unknown's thoughts on Wedge
Post by: Dragooon on June 28th, 2011, 11:38 AM
Quote from [Unknown
link=msg=263240 date=1309240621]
I'm 25, so I guess I was about 17 when I started working on SMF.  Certainly have learned a few things since then.

Dunno about whizzkid, essentially I spent the couple years after high school working on SMF before I got a job.  It's much easier to get a lot of things done when you don't have other obligations etc. yet.  More a function of circumstance.

-[Unknown]
You are 8 years older than me...meh old people! So you didn't got to a professional university?
Quote from Nao/Gilles on June 28th, 2011, 07:49 AM
How old are you, Unknown?
If you're younger than Pete is, does that mean you were one of those Dragooon-like wizkids back when you started SMF?

I hate those fucking wizkids, they always end up being faster and better than me :niark:
Why, thank you!
Title: Re: Unknown's thoughts on Wedge
Post by: Nao on June 28th, 2011, 12:01 PM
Quote from Dragooon on June 28th, 2011, 11:38 AM
You are 8 years older than me...meh old people!
Go back to your kindergarten!!
Quote
Why, thank you!
I hate you I hate you!

(boohooohoooooooooooooooooo........ :sob:)
Title: Re: Unknown's thoughts on Wedge
Post by: tradenet on June 28th, 2011, 07:49 PM
(Reaches for Oil of Olay®)
Title: Re: Unknown's thoughts on Wedge
Post by: Arantor on June 28th, 2011, 10:55 PM
OK, so I've had time to settle, digest and figure out what I want from this, and why, including what I want as a regular admin/user as well as a mod developer.


I want mods that do not have to rely on version checking. I want to avoid all the explicit checks that SMF has to make.

I want it so mods will *most likely* work between different versions. There are so many threads and questions about mods that only state a given version or versions, and whether they'll work on a later version. Even with SMF's policy of pushing out patches, people still ask whether a given mod will work or not because most people don't know or want to have to get involved.

Going primarily hook based means this sort of thing can be minimised because you have a setup whereby you can tell what mods are "most likely compatible" automatically, by whether a given mod requires what hooks and whether those hooks are present or not.

Having direct edits threatens this on a variety of levels, because you can't really determine *reliably* if it'll work. All you can do is validate whether the same code still exists or not which from bitter experience, isn't that reliable.

Retaining file edits does encourage version dependent coding. It also doesn't discourage abandonment - mod authors, generally, want to do as little as possible to maintain their mods. Making them do any more work will discourage them from writing mods. There are a great many mods on sm.org that are perfectly functional on current versions, but due to version checking brittleness, aren't used (and breed questions as above)

That said, there is a place for file edits. If they were used, the version checking would have to be used - that alone should be fair motivation for them to avoid doing file edits where possible.

As a user, I just want them to work. I don't want to have to fudge version checks with version-emulate, no matter how convenient it is to override it. I want it to work and not have to inconvenience the mod author any more than necessary. (And if I can encourage them to do it a better way by making it less work for them, awesome.)

I also know from bitter experience that mods editing files can be a pain. Incidentally, the problem is confined to specific classes rather than general. Most of my mods never had many problems because I was careful to avoid making more edits than necessary, and I would go to ridiculous lengths to avoid template edits except in the admin templates (e.g. SD 2.0 edits the IP tracking area of the profile, the manage attachments template and the packages template, and that's it, despite interacting with the board index and the main index templates)

What tends to happen is that mods which hit up the same place tend to collide, for the obvious reason, not only code collision but mods conflict with each other subtly; there's a mod, for example, that converts the board index layout to have a separate posts and topics column rather than a unified column - but any mod that then tweaks the layout (or has a different layout entirely) is going to conflict. (As it happens, I did most of this for SD in one of the output buffers, so it wasn't an issue)

Thing is, that's not going to go away, even with hooks. But it will be a lot easier if done with hooks and made easier to manipulate.

The consequence is that manual intervention is deemed the norm, even expected. It's hassle for the mod author and hassle for the user, and separating it structurally will make it easier. But it won't fix everything, so hooks will possibly make it more complex, but could often solve most of the problems if done properly.

So, let's assume for the present that we do preserve file edits, and that we make it discouraged (big warnings, etc.), we still have to contend with file permissions. I have seen far too many cases where file permissions are a headache, even with WordPress upgrade installs, and I dislike the problems it causes:
1. It makes people have higher permissions than they actually need.
2. It is a major cause of people hitting mod_security errors where they throw 777 permissions at everything.
3. It is very likely also a contributor towards installations being compromised and hacked. That was partly why the krisbarteo hack in 2009 was so successful, so many setups had permissions they shouldn't, meaning a dangerous attachment was able to trigger and infect any SMF files it could find. In some cases it was even observed to be the entrance for an entire server to be compromised.

While it can be 'made more reliable', I have lost count of the number of support issues that emerge every single day with SMF because of file permissions. Admins don't want to be bothered by it, they just want to install things without having to run a gauntlet. They just want to, at worst, set it up once and then it's done.

Add to that, people are naive. I have also lost count of the number of people who deleted a package and expected it to be removed. More than that, if a single file edit is going to fail, most people will assume there is a problem with the mod, plus most mod authors end up being expected to field problems with installation even if it's an SMF issue.

I could go on, I can find you more and more reasons to discourage file edits, and I hope this is enough to discourage mod authors where possible.

I mentioned before about specific classes of mod having issues. It's funny how the classes of mod that have trouble are that already mentioned, and the big mods. I remember in the early days having to spend time juggling SD's code to avoid tripping up on the portals, and even then people still have to uninstall things in the right order. This is something that, as far as I'm concerned, should just not be necessary for typical users to have to contend with.

It also implies a mod registry in the database being maintained, and having seen how many times there have been problems with this, it's even more a cause for concern (any mod that's manually installed will not appear in any of the registries unless the install was still performed and failed edits done afterwards)

What I propose, then, is that hooks are strongly encouraged (and, let's be honest, I expect to write most of the 'most wanted' mods myself) but that we do keep file edits. But, not only do we have warnings, we make the user have to manually enable it first, to understand all the consequences. Plus, we can manage it through the repository to advise the user that manual edits will be required.

In other words: I'm prepared to accept mods doing file edits if we make it a not unreasonable hurdle, and to use hooks for most things, because while file edits are convenient for the modder, they're not beneficial for the user, and it actively makes it harder to work on in the long run.

I still think it will cause friction because modders are still going to do that because they're used to it. I also think it will breed all the bad habits that SMF has - and I would rather breed a better experience for users than the developer experience, but I can see the benefits to keeping file edits.

I would retain the warnings etc even for Wedge patches because I don't see it being any better. Our intention for updates is for proper upgrade packages like SMF's rather than patches, which is better when using hooks because you don't have to wait for modders to update and in most cases you can update and just carry on using mods as you were before.

Mods that require direct edits will naturally require version bindings, but everything else can be function detection based. I'll be sure to write mods that don't require file edits, and since that will settle a decent proportion of the 'most wanted', I suspect it'll encourage good habits.

But I think any more than that will be a case of putting out the tools and hoping developers make use of them - we can encourage, we can demonstrate but we can't make them do it... and if we did *make* them, we'd be no better than the environment we left behind, and to me it would compromise the very freedom that Wedge was founded on.
Title: Re: Unknown's thoughts on Wedge
Post by: Nao on June 28th, 2011, 11:18 PM
The best way to encourage modders to use hooks is to remind them that Wedge will never get upgrade patches -- only full releases (or possibly small releases with only the updated files.)
Title: Re: Unknown's thoughts on Wedge
Post by: Arantor on June 28th, 2011, 11:28 PM
That's the thing: it could be a good kick up the arse to do it right the first time, or a middle-finger because so many modders wouldn't sit and maintain mods for different SMF RCs, which is virtually the same thing on a technical level, if not a semantic one.

Plenty of examples and docs should help though.
Title: Re: Unknown's thoughts on Wedge
Post by: Nao on June 28th, 2011, 11:44 PM
Sure.

(Go answer the Font topic, you naughty!)
Posted: June 28th, 2011, 11:38 PM

Oh well I'll just go to bed...
Title: Re: Unknown's thoughts on Wedge
Post by: groundup on June 29th, 2011, 03:55 AM
Arantor, at some point you are going to need to rely on versions or you will never move forward. You can loosely couple but if you overdo that, you wind up with Limp instead of Wedge ;)
Title: Re: Unknown's thoughts on Wedge
Post by: Eros on June 29th, 2011, 04:48 AM
Well, Arantor, for what it is worth...I agree with that choice, even if I think motivating developers out of bad behavior can't be done with file edits vs. hooks. ;)
Title: Re: Unknown's thoughts on Wedge
Post by: Nao on June 29th, 2011, 07:36 AM
I'd like to reiterate my original idea.

Disable file edits at least until Wedge is out of beta.
If people rely on file edits when they can't find a hook, we'll never get people to get us to add hooks.
Title: Re: Unknown's thoughts on Wedge
Post by: Arantor on June 29th, 2011, 10:12 AM
Quote from groundup on June 29th, 2011, 03:55 AM
Arantor, at some point you are going to need to rely on versions or you will never move forward. You can loosely couple but if you overdo that, you wind up with Limp instead of Wedge ;)
Other than for file edits, why do I have to rely on versions?
Title: Re: Unknown's thoughts on Wedge
Post by: Arantor on June 29th, 2011, 10:49 AM
See, here's what people don't realise about me.

Before I came to PHP, I did ASP.Classic, and before that, Visual Basic itself. Except I was doing stuff using the Windows API itself because VB's own set.

And the stuff I wrote 10 years ago... with one exception, it all still works on Windows 7. That particular exception is because of an API that was deprecated back in 2000, and naturally doesn't exist now. If you can do this on an operating system, why can't we apply the same basic techniques to programming in a higher level environment?

As far as what I want Wedge to be, I want to take SMF and fix what I see as the problems in it, mostly for users but solving some of those that I saw for modders too. I want to be able to write extensions for it that don't require me to babysit them as versions change unless something dramatic happens.

SimpleDesk was mentioned earlier on; I want to be able to create a counterpart for Wedge that doesn't require version specific hacks. I want to be able to create something that big and scary that runs on multiple versions and doesn't require me to patch it, or update its listing, just because a new version of Wedge came out.

I want to be able to port my mods to Wedge. I want to be able to write some of the other mods I've thought about over the last 2 years, except the frustration involved in writing most of them in a way that won't cause me to do support is why I didn't.
Title: Re: Unknown's thoughts on Wedge
Post by: Arantor on June 29th, 2011, 01:06 PM
Oh, of course they could be updated, because I've learned a great deal in the last decade. But here's the thing: won't someone PLEASE think of the users? :P

Innovative is nice, but so is building something that doesn't make me feel like it's a ball and chain tying me down. I do not want to find myself in a year's time feeling burned out from having to deal with the support requests that SMF has to deal with.
Title: Re: Unknown's thoughts on Wedge
Post by: Nao on June 29th, 2011, 05:39 PM
But it becomes manageable -- and by OTHERS :P
Title: Re: Unknown's thoughts on Wedge
Post by: PantsManUK on June 29th, 2011, 06:24 PM
Lots of interesting technical talk going on here, so I thought I'd chip in with an "end user perspective".

I just want shit to work, and that's all.

If/when we move to Wedge, I don't want to have to remember what order I installed things on the off-chance I end up with an upgrade to a mod that I installed 4 years ago (it's happened twice now...). I don't want to have the endless file-edit hell that is/was PHPBB (when we ran that) because plug-in mods was one of the main reasons we started using SMF.

Now, if "you" can manage to keep mods working across version updates, I'll love you forever; having to (re)install mods every time the host app changes isn't fun (can anyone say "SMP minecraft server"?)
Title: Re: Unknown's thoughts on Wedge
Post by: verm on June 29th, 2011, 07:09 PM
IMHO, minor version upgrades (or patches) for the same branch, i.e. ver 1, the mods should be independant of the minor changes to the codebase...

Even with major upgrades going from one branch to the next, using hooks should allow mods to be compatible (or backward compatible) unless the codebase is refactored...

But a hook is still a hook, even the codebase is totally changed then the changes to the function/class doing the hooking should be backward compatible...

I am talking nonsense is it not...

Anyway, to simplify my point, one site I administer is using SMF 2 RC5 will plenty of mods...now with SMF 2 Final, I am reluctant to upgrade since it will involved the same amount of work during the initial installation; that is checking if the mod is compatible with the version and re-install...
it would be better to simply upgrade the forum software only without all the hassle of checking the compatibility of the mods since to me it come from the same branch
Title: Re: Unknown's thoughts on Wedge
Post by: [Unknown] on June 30th, 2011, 10:00 AM
FWIW, just to be clear:

I do agree that most mods should be made with hooks.  I just don't think it's possible for every single mod, and I think it's limiting.  If the average user has more than one mod that does direct edits (excluding updates), that may be a bad thing.

And again, some of the issue is "contention" for certain areas of SMF that are common to modify.  For this reason, conflicts and problems and order-of-installation are much larger problems.  Every area of contention definitely should be a hook, solving that issue.

With that said...


Quote from Arantor on June 28th, 2011, 10:55 PM
I want mods that do not have to rely on version checking. I want to avoid all the explicit checks that SMF has to make.
Hmm.  I agree that SMF is probably overly cautious with version number requirements.  I based the model on Firefox, which I think has laxed up their requirements a bit.  I'm going to save this for later.  If it had enough users, something like the Add-on Compatibility Reporter could help the situation.
Quote from Arantor on June 28th, 2011, 10:55 PM
It also doesn't discourage abandonment - mod authors, generally, want to do as little as possible to maintain their mods.
I suggest this is a separate issue.  I see no reason why hooks don't discourage abandonment (work or no work.)  I think you mean to assert that abandonment itself is less of an issue with a hook-only system.

But ultimately, I think abandonment affects everything - offhand, it doesn't seem like things that are abandoned are popular in any context, for a number of good (logistical) reasons.  They may work, but all software has bugs, and so do modifications, so abandonment is always an issue.
Quote from Arantor on June 28th, 2011, 10:55 PM
version-emulate
I don't know what this is but it sounds like a bad fix for a good problem.
Quote from Arantor on June 28th, 2011, 10:55 PM
(And if I can encourage them to do it a better way by making it less work for them, awesome.)
I think a sane approach to attempt would be to change the format from what SMF uses drastically.  Have an optional or required minimum version number, and have an optional (and never used in the examples) maximum version.  You'll probably disagree with me, but I do think there is a place for a maximum version.

I don't think a lot of mods used it, but the intention was for one mod to be installable in more versions of SMF.  But because SMF went 4 years without a major update, this didn't end up being useful.  Maybe it's not actually that useful, but there is Windows software and various other things that have BC code that is applied to older versions.

Consider, a mod that comes with a bugfix (or maybe a dependency to a common bugfix mod) for an older version, such as SMF 1.1.  This bugfix is one that, for stability reasons, was not backported to 1.1.x proper, but exists as a checkin.  This is a common thing that happens in software all the time.  The package manager was designed (but never documented) to handle this case, so that it could optionally install some backported bugfix that affected the mod, but did not really affect SMF itself much.
Quote from Arantor on June 28th, 2011, 10:55 PM
I was careful to avoid making more edits than necessary
Template edits in SMF are a huge problem, and a very separate one in my mind.  The issue there is the propagation and full-file defaulting, and also the lack of any sane way to modify small pieces.  TOX-G was designed to solve each of these problems in the simplest way possible.
Quote from Arantor on June 28th, 2011, 10:55 PM
What tends to happen is that mods which hit up the same place tend to collide, for the obvious reason
Right.  This means that they are contending for that area of code, which means a hook should exist to handle what they are trying to do.  Definitely.
Quote from Arantor on June 28th, 2011, 10:55 PM
but any mod that then tweaks the layout (or has a different layout entirely) is going to conflict.
There will always be small conflicts, when a user applies to mods that try to do separate things to the same thing.  Chaining can't always fix this - imagine a mod that converts the recent posts to be rendered using JavaScript, and updates live with a long-running PHP script (or even, possibly, a connection to something else, such as node.js, for efficiency.)  While a very reasonable use case, and possibly a useful and cool mod (but, if it requires node.js or inefficient long-running PHP, probably not something for the standard distribution) but would probably very much conflict (even if no error messages during package install) with anything that modified the recent posts in any other way.

But you note that it won't go away, I'm just giving a real-world use case.
Quote from Arantor on June 28th, 2011, 10:55 PM
1. It makes people have higher permissions than they actually need.
2. It is a major cause of people hitting mod_security errors where they throw 777 permissions at everything.
3. It is very likely also a contributor towards installations being compromised and hacked.
I'm confident that the problems are solvable.  I made changes to the webinstall.php file, and couldn't find anyone that had problems using it even on servers with mod_security, suhosin, CGI suexec, or etc.

The intention was for the package manager to automatically run the change file perms routine after installing, or else set files back, but I was concerned about some of the details (such as a mod adding files that did or did not need to be writable.)

The package manager was one of the first things I changed, and the main thing I did was move it from boardmod to a format that provided more options and detail, because of some of the annoyances I had had with boardmod.  File permissions at that point were kept the same, and quite frankly, I didn't even think about it until people started mentioning it.

Also, it was popular then (as it still is now) to run PHP in an insecure setup where PHP can always change its own files.  This was considered by many to be the most secure setup, and at first I believed them.  I understood the drawbacks of the other popular method (PHP as a single user on shared servers) and basically figured there was no way around that risk because of the db password and attachments directory.

I would probably take it more seriously now, and also more aggressively and clearly indicate the correct and secure setup for file permissions and PHP to run on any server.
Quote from Arantor on June 28th, 2011, 10:55 PM
That was partly why the krisbarteo hack in 2009 was so successful
I don't know the specifics, but it looks like it was a file-uploaded-but-shouldn't-have-been-allowed type of issue, or maybe a CSRF.  Assuming this is true, and attachments or cache are writable, you're probably screwed no matter what.

I know of another hack that people blame on file permissions, which infects files with <script> and such, generally with names like index.php, index.html, default.html, etc.  This is a client side hack (which might be delivered by a compromised HTML, jar, etc. file) that uses your FileZilla/SmartFTP/Dreamweaver/etc. saved FTP settings.

The only true way to fix this issue is to encourage the separate partitioning of uploads.  For this reason, I suggest S3 or making it the default option to enter an FTP account setup to store uploads in.  This encourages better practices.
Quote from Arantor on June 28th, 2011, 10:55 PM
While it can be 'made more reliable', I have lost count of the number of support issues that emerge every single day with SMF because of file permissions.
Incidentally, the webinstaller can do a better job at installing with the correct file permissions (and not mangling file names) than the average user would using an FTP client and the Wikipedia entry for CHMOD.  I wouldn't expect these questions and problems to go away even without the package manager.

I think the problem is that no one took the initiative to test and track down the issues.  They just figured that some workarounds were this and that and SMF could never really do it.  Add 4 years.  Kinda silly in my mind.
Quote from Arantor on June 28th, 2011, 10:55 PM
I could go on, I can find you more and more reasons to discourage file edits, and I hope this is enough to discourage mod authors where possible.
I don't think file edits are "easier."  You have to edit, and then pull out your changes.  In any significantly different codebase, this won't be preferrable to "edit the php file that hooks, and see your changes immediately, and then zip that exact file without additional testing needed."  As long as people have good examples to go from, I don't think they will lean on file edits unless necessary.
Quote from Arantor on June 28th, 2011, 10:55 PM
we make the user have to manually enable it first, to understand all the consequences. Plus, we can manage it through the repository to advise the user that manual edits will be required.
I still think you want updates applied in an automated fashion.  I find asking a user to fire up an FTP client (and what that is is not common knowledge, at least in my experience) to install updates more or less draconian.

I walked a client through installing a software that's installed in the typical draconian fashion.  She did end up figuring out FTP, but wasn't really sure on the chmod parts and I ended up having to help her.  She took notes, and learned from the experience, but ultimately I can be fairly confident she will never upgrade that software, because installing it was enough of a hassle.

That's why I see going back to the "upload the contents of this zip file" model kinda like trading in a shiny new Prius for some car from the early 1990's that gets terrible mileage and barely passes emission standards.  It's hard for me to even understand the motivation, even if you think the electric engine in the Prius is a bit complicated or causes problems sometimes.
Quote from Arantor on June 28th, 2011, 10:55 PM
But I think any more than that will be a case of putting out the tools and hoping developers make use of them
This is always the most important thing.


Quote from Nao/Gilles on June 29th, 2011, 07:36 AM
I'd like to reiterate my original idea.

Disable file edits at least until Wedge is out of beta.
If people rely on file edits when they can't find a hook, we'll never get people to get us to add hooks.
That doesn't seem crazy.  That said, if you add a hook for every possible file edit, I promise you that you'll regret it later.  More on that later.
Quote from Arantor on June 29th, 2011, 10:12 AM
Other than for file edits, why do I have to rely on versions?
A number of reasons (although if there's enough semantic hook detection, this can be mitigated.)

A well developed mod will be shipped as one version, even if there are multiple popular current branches of Wedge currently being used.  In some fashion, different hooks need to be installed potentially for different versions - consider that Wedge 2.0 adds a new hook that this mod wants to use, but in Wedge 1.x, it needs to use other hooks (or file edit the hook in, for BC.)

This can be mitigated by some sort of hook detection, but this has its own set of problems.  One option is to run plugin init code on every page view, but this has performance problems with many mods.  Another is to re-run hook init logic for every different version number internally and/or whenever plugins are installed/removed, so the logic can be updated and cached.  This has its own complications, mostly that it isn't simple to write.

I imagine you'll want a minimum version.  I can't think offhand of any system that doesn't allow for a minimum version requirement.
Quote from Arantor on June 29th, 2011, 10:49 AM
And the stuff I wrote 10 years ago... with one exception, it all still works on Windows 7. That particular exception is because of an API that was deprecated back in 2000, and naturally doesn't exist now. If you can do this on an operating system, why can't we apply the same basic techniques to programming in a higher level environment?
This is a fairly easy argument to refute.  I'm going to keep it brief because it's getting late, and I need to get some sleep, but:

1. Apps are not mods.  If your intent is to only support apps in Wedge, like Facebook apps and iPhone apps, then file edits are pointless.  That seems a silly place to aim for, IMHO.

2. Drives have had major version requirements in Windows.  Obviously you never wrote a driver.

3. Have you ever tried to change the task bar, Alt-Tab menu, or install tabs in Windows Explorer?  I have done all of these things.  They are highly Windows version dependent.

4. Microsoft has but a lot of effort and man hours into maintaining compatibility heuristics, rules, and settings in Windows.  Maybe you've never noticed them, which is a testament to them doing something right.  It's quite possible they are responsible for making your apps work, in some cases (especially where UAC might be concerned.)  Are you intending to put in that level of effort?

5. Zip tools often had major problems with Windows updates when they came out with XP, which had its own zip tool that stomped over people's existing integration methods.  ConTEXT also had some issues, although they were worked out.  I know tons of software has had to be updated for UAC as well.

6. Windows' API is full of compatibility functions.  Did you realize, every function in the API has two versions?  An "A" version and a "W" version.  The W versions were added later, and support Unicode.  The A versions support multi-byte encodings where the codepage is set properly.  They maintain both versions and it's a huge overhead.

7. There are bugs in many of Windows' APIs, some of which are documented, and must stay that way for compatibility.

8. Were you aware that Windows programs define the version they intend to compile against (although usually this is done for you automatically)?  Windows then may enable certain bugs in API calls or etc. so that it will work more like that particular version.

Are you intending to do all of these things and deal with all of these problems?
Quote from Arantor on June 29th, 2011, 10:49 AM
I want to be able to port my mods to Wedge. I want to be able to write some of the other mods I've thought about over the last 2 years, except the frustration involved in writing most of them in a way that won't cause me to do support is why I didn't.
If it's a hassle, it needs to be fixed, agreed.  There are compromises to do this without veering into an unknown space that may have its own new set of challenges not yet imagined.
Quote from Bloc on June 29th, 2011, 12:40 PM
Sounds ambitious, and in a way i see what you mean, I like to write themes or mods too, that will always work, or don't rely on anything changes etc. But i think thats an utopia, as long as the host script changes, you need to change with it. And the host script need to be possible to change, your knowledge will change, technologies arrive that require it etc. I bet your old programs, while they still run, could use updating still. Being content with it "just working" doesn't bode well for innovatism IMHO...

But I've love to see me proven wrong of course lol. :)
With themes, I think it's mostly impossible.  But I'm hoping that if they are organized right, the correct parts can be frozen, and most themes can be written to just modify all the parts that are common that don't need changes, and the main code can use overlays to apply to older themes to add new features, such as new fields.



Which brings me to "freezing."  With any API, including a hook API, freezing is important.  This is something SMF never did and it paid for it.  Facebook also (purposefully, I'm fairly sure) does not freeze their APIs, whereas for example Google does freeze their APIs.

A frozen API means that it doesn't change.  Once you sent the parameter the wrong way, you're living with it.  You're passing an id and you want to pass an object now?  Too bad.  It's frozen.  You have to create a new hook.

Some people think freezing is a bad thing, and leads to stagnation.  Making it "wrong" to improve the code means that the code will get messy, and have more weird problems in it.  This is why some developers intentionally do not freeze their APIs.

I personally prefer it, though, because it means that compatibility can be achieved in some sane way.  When I trust an API is frozen, I'm much more interested in writing for it, unlike an API that I expect could easily change within a couple months invalidating my work.  It sounds like you agree, and also want this.

Just want to mention some of its detriments so they are not ignored:

1. When freezing APIs, most people take the course of making as few as necessary.  This is because, the more you have, the more locked doors you're putting in the way of your own development.

2. These APIs also typically either have feature branches (which can be detected for) or versions, and phase out older versions or feature branches over time.  This means additional management and documentation overhead, but it's not too bad.

3. You should think hard and probably have a review process on hooks before they are finalized, so that the pains of maintaining "I wish I'd never made that hook" problems go away.

4. You need to consider more carefully what happens when a feature is heavily overhauled.  For example, suppose hooks were used in the personal message system, prior to it being changed in 1.1 iirc to have labels and such.  You have to make a decision to design the new features around the hooks, or to throw the hooks out, or do a shade of grey in between.

5. Also, with hooks, you have to carefully consider chaining, which is a more important issue than it may seem at first.  When using frozen APIs, this gets more complicated: suppose you implement an "extended" version of the hook in a new version, whilst retaining the old.  Now a user has two plugins, each using the hook, but different versions.  You have to handle the chaining.


Quote from Arantor on June 29th, 2011, 01:06 PM
Oh, of course they could be updated, because I've learned a great deal in the last decade. But here's the thing: won't someone PLEASE think of the users? :P
I don't think users like dealing with order-of-installation issues, or contention issues, or any of those things.  I also don't think they like dealing with manual edits or uploads, incompatibilities, or etc. either.  Users also don't want indirect problems like core development slowdown or not being able to upgrade because a new version has different hooks.

Trying to think only of the user often ends up ignoring a significant part of their concern.  Best to think of everyone and only prioritize the users where possible, IMHO.

That said, I know that you care about the users already from past conversations, and that's a very good thing.  I'm not knocking that at all.
Quote from PantsManUK on June 29th, 2011, 06:24 PM
Now, if "you" can manage to keep mods working across version updates, I'll love you forever; having to (re)install mods every time the host app changes isn't fun (can anyone say "SMP minecraft server"?)
This was just one of the historic "bad decisions" we made.  This came up several times while we were working on the feature.  I noticed it and considered it, we talked in the dev team about it, and the team discussed it.  But usually briefly, and the answer was always "ah, it's fine to reinstall every time."

I agree that was a bad decision, but the reality is we just didn't think it was a huge problem, and at the time, there weren't a whole lot of mods to reinstall anyway.  After that, it sorta got baked into our heads a bit, and so we stopped considering the idea of trying to retain installed mods on upgrade.

At one point, someone had proposed a more robust system, that tracked exactly what to do, installation order if necessary, and did a dry run unapplying, updating, and reapplying, and told you which mods weren't compatible that way.  I don't remember how it totally went, but we didn't do it because we figured the effort wasn't worth it.

In part, we really weren't considering the case of many mods being installed.  This was in part an over-reaction to "Supermod", which for YaBB SE was this ugly, Frankenstein thing that was a scary mess that had all sorts of fun bugs and made mod authors mass delete their mods.  Because of the issues there, I think none of us were really thinking of lots of mods as a reasonable use case at all.

Still, I'm always surprised that things like that didn't change in the last 5 years.
Quote from TechTitan on June 29th, 2011, 07:09 PM
Anyway, to simplify my point, one site I administer is using SMF 2 RC5 will plenty of mods...now with SMF 2 Final, I am reluctant to upgrade since it will involved the same amount of work during the initial installation; that is checking if the mod is compatible with the version and re-install...
it would be better to simply upgrade the forum software only without all the hassle of checking the compatibility of the mods since to me it come from the same branch
Presumably, not a ton of code has changed between SMF 2.0 RC5 and SMF 2.0, right?  So in theory, this sounds right.  I'm not sure what it means to check the compatibility; from context, I assume this is some manual process?

Let me ask you this.  The mods you have installed now, did you have to make any manual edits to install them all successfully?  I don't know if you have a bunch or if you use themes, but if the answer to either of those is yes, I presume you had to do manual edits, and you're wanting to avoid making those again, right?

I assume there is an update package for SMF 2.0 RC5.  I'm guessing it does not apply cleanly on top of your existing mods, right?



Separately, I think that Chrome handles these very well, although as mentioned, there are buggy extensions that don't work in the current version.

If you've ever built one, you'll know that it automatically packages things easily for you, and also that it uses permissions:

http://code.google.com/chrome/extensions/permission_warnings.html

These are a common concept in integrations now, and something I strongly recommend for Wedge.  I would imagine that file edits might be a permission.

-[Unknown]
Title: Re: Unknown's thoughts on Wedge
Post by: Paracelsus on June 30th, 2011, 10:30 AM
Quote from Bloc on June 29th, 2011, 10:28 AM
But maybe you should back up abit...what exactly IS the purpose of Wedge? A forum alternative to SMF with extras? or a "soon-to-be-core" script that can accept plugins, and just happens to be a forum in nature..? Not saying one or the other is better in any way(done my share of making SMF into something more for example lol) but whatever direction you are headed will also influence the question of using file-edits versus hooks/plugins.
Wise words.

As an end-user I guess I prefer Arantor's way of doing things, having to deal less with issues related to the technical implementation (lack of system awareness for outdated/updated versions, file-edits from a mod that conflict with another mod, having to change file and folder permissions back and forth, etc), and being much more interested in having defined groups of modifications that are a world "per se" and where the discussion focus is on the features built into each mod.

Although I value a lot SMF's flexibility of being able to change almost every imaginable thing in the system I just love mods like SimpleDesk (which is a very nice piece of software, congrats Arantor!) or AEVA, the way they install, uninstall and upgrade without issues with the core and then the amazing gui and amount of freedom and features they provide inside the mod itself (which to me cover 99% of the aspects I would like to be able to customize in such a mod).

If this is the way for Wedge, I say go for it... maybe you won't get the same level of contributions from external coders (since it's a more "controlled" product), but you'll make your end-users and those who administrate the forums very happy. ^_^
Title: Re: Unknown's thoughts on Wedge
Post by: [Unknown] on June 30th, 2011, 10:54 AM
Quote from Dragooon on June 28th, 2011, 11:38 AM
So you didn't go to a professional university?
Oops, sorry, almost missed this post.

Well, no, I didn't.  Some life happened and other complications got thrown into the mix.  There are a few things I didn't get to do during that period that I had originally intended to.

Don't get me wrong, I didn't work on SMF instead of going to a university/etc.  Rather, life happened, and those weren't immediate options, so I worked on SMF instead.  Ultimately, it was a great experience, and no matter what mistakes I made or didn't make, I grew a lot from it.

Although I think college/university is a fairly important thing, I did luckily study a lot of subjects in high school, and since then I have spent a lot of time keeping up on RFCs, recommendations, other project's management and code review practices, etc. in order to keep myself versed.

If it weren't for those things and SMF, I definitely wouldn't be where I am now (professionally.)  It's really impossible to guess whether having gone to college/university would have changed that, considering how much I learned from working on SMF... IMHO.
Quote from Paracelsus on June 30th, 2011, 10:30 AM
Quote from Bloc on June 29th, 2011, 10:28 AM
But maybe you should back up abit...what exactly IS the purpose of Wedge? A forum alternative to SMF with extras? or a "soon-to-be-core" script that can accept plugins, and just happens to be a forum in nature..? Not saying one or the other is better in any way(done my share of making SMF into something more for example lol) but whatever direction you are headed will also influence the question of using file-edits versus hooks/plugins.
Wise words.
Yes, ultimately, if they just want a forum that supports "apps" like a gallery, a portal page, etc. then it's all a moot point.  I personally wouldn't be satisfied with apps, but it's a question of audience, I suppose.
Quote from Paracelsus on June 30th, 2011, 10:30 AM
If this is the way for Wedge, I say go for it... maybe you won't get the same level of contributions from external coders (since it's a more "controlled" product), but you'll make your end-users and those who administrate the forums very happy. ^_^
I think that administrators can be made happy without having a rigid product.  Ultimately I see both extremes as "unhappy administrators" just for different reasons.

-[Unknown]
Title: Re: Unknown's thoughts on Wedge
Post by: Paracelsus on June 30th, 2011, 11:21 AM
Quote from Unknown on June 30th, 2011, 10:54 AM
Quote from Paracelsus on June 30th, 2011, 10:30 AM
If this is the way for Wedge, I say go for it... maybe you won't get the same level of contributions from external coders (since it's a more "controlled" product), but you'll make your end-users and those who administrate the forums very happy. ^_^
I think that administrators can be made happy without having a rigid product.  Ultimately I see both extremes as "unhappy administrators" just for different reasons.

-[Unknown]
You're entirely right, like you said it's a question of audience.

I think SMF is very very "balanced" when it comes to integrate stuff and still allowing for expert and advanced programmers to make their own unique product.

SMF is probably the forum software that achieves the best of both worlds, but for Wedge to be something different it needs to define itself. Actually the word Wedge suggests something less "rigid", more [Unknown]-style. ;)


PS: Damn, your name with brackets in the quote - removed them right now - just breaks the whole layout... a bug I would say.
Title: Re: Unknown's thoughts on Wedge
Post by: verm on June 30th, 2011, 02:36 PM
Quote from [Unknown
link=msg=263307 date=1309420832]

Presumably, not a ton of code has changed between SMF 2.0 RC5 and SMF 2.0, right?  So in theory, this sounds right.  I'm not sure what it means to check the compatibility; from context, I assume this is some manual process?

Let me ask you this.  The mods you have installed now, did you have to make any manual edits to install them all successfully?  I don't know if you have a bunch or if you use themes, but if the answer to either of those is yes, I presume you had to do manual edits, and you're wanting to avoid making those again, right?

I assume there is an update package for SMF 2.0 RC5.  I'm guessing it does not apply cleanly on top of your existing mods, right?

-[Unknown]
Its sure enlightening reading all your comments (I came to know SMF when you already left)... :thanks:

Yes, some of the mods I installed involved manual edits (made for RC4 and install in RC5) and I think I modified one mod to feature 'Member for xx days'...

It is quite troublesome to remember what and where I made the edits months ago..

Since I myself not a programmer and only doing a little bit of code hack once in a blue moon, I think having mods that use hook will be lot simpler for administrators like me to maintain their forum...but I still like the challenge of making direct edits..

I applied the update but in a test environment (cloned the site) and I think I need a clear mind and lots of coffee before I proceed... :lol:


Title: Re: Unknown's thoughts on Wedge
Post by: MultiformeIngegno on June 30th, 2011, 03:06 PM
I think that conflicts and manual edits are a pain in the arse.. :P
Long life hooks! Go Arantor!!
Title: Re: Unknown's thoughts on Wedge
Post by: Arantor on June 30th, 2011, 04:09 PM
Before I answer the rest, as I only just got home, I want to answer one point.

I pretty much came into really writing SMF mods around RC1 emerging, and had to contend with changes of code between each of the RCs. Each upgrade of SMF therein was a full upload-of-files-on-top-of-the-old, with the exceptions of 2.0 RC1-1, 2.0 RC1.2 (security patches on top of RC1, mirrored in 1.1.9 and 1.1.10) and a patch for 2.0 RC4.

And this has been the case for 2 years. Yet adoption of 2.0 still occurred, in spite of the fact that users had to reinstall - but upgrading was held back. There are plenty of users still on RC3 because the mods weren't fixed thereafter - a number of mods did play nicely and targeted comments in the source, as opposed to code that might change, and then the dev team tidied up the comments by fixing typos and so on.
Title: Re: Unknown's thoughts on Wedge
Post by: Arantor on June 30th, 2011, 06:46 PM
Quote
So yeah, one can spew all over bad decisions, poor coding, not enough visions
FWIW, I don't care about who did it, or even why. It's simply not relevant any more. What I'm trying to get at is what happened, and what resulted because of it in terms of how it affects what we do going forward.

The point being made, which was clearly missed, is that the full upgrade cycle being pushed every 6 months, give or take, combined with mods having to be reinstalled (assuming mod authors bothered to update) was a major PITA for most admins. It has led to a great number of admins just not updating their installations, even leaving them rather dangerously insecure.

That, combined with the fact that mods could not be reliably guaranteed to work between even RCs (I remember having to give SimpleDesk specific code changes between each and every single RC, and a further change because of a regression bug in 2.0 final, though in each case other than the last, I'm not disputing that the result was for the better) and the fact that modders were sometimes lynched for not getting updates out within *hours* of a new release, it put a lot of them off updating until final. This is a cycle I do not want us to get locked into, and why for the most part I'm pushing people away from manual edits.

It was mostly a statement in response to Unknown's question about upgrading from 2.0 RC5 to final being a full update (which it is, unless you're insane enough to go through and make the changes to each file by hand, as I did in Wedge's case)

Anyway, now to answer the meat of stuff.
Quote
I do agree that most mods should be made with hooks.  I just don't think it's possible for every single mod, and I think it's limiting.  If the average user has more than one mod that does direct edits (excluding updates), that may be a bad thing.
Ah, that means I've been reading between the wrong lines. The apparent level of enthusiasm for raw edits seemed to suggest otherwise ;) It also means we're far closer in thought than I'd actually envisaged. Though, honestly, I was prepared to let mod authors who need manual edits deal with it themselves (much as you'll find in some of the other communities)
Quote
And again, some of the issue is "contention" for certain areas of SMF that are common to modify.  For this reason, conflicts and problems and order-of-installation are much larger problems.  Every area of contention definitely should be a hook, solving that issue.
Yes, that's the plan. I look to SimpleDesk on this one: there are some places I do actually do template edits in SD 2.0, and even though I hate the general concept of having to do that, I'm not entirely uncomfortable about it because of the specificity of the templates and of the changes themselves. It is unlikely that many mods would ever update the track-IP screen or the manage-attachments screen unless they had very, very good reason (and SD does, in both cases) - and since they are uncommon templates, I'd never had a conflict.

The main areas for conflict in SMF are the admin panel, the main menu, the permissions code and the actions list, all of which got hooks in RC4/5. One for the credits page would have been good, as would for the 'illegal permissions' setup. But there are plenty of places that hooks would be useful and aren't - such as in the post view to add more things to work with in terms of styling (like the suggestion I made about putting the topic author in to the post as a CSS class, for example). Not all things are expressly hook points as we normally think of them.
Quote
But you note that it won't go away, I'm just giving a real-world use case.
Oh, I have plenty of real-world cases to draw from, and have had to deal with. The reality in the end is that you can't fix everything, but that you can design other things to minimise the problem. SimpleDesk does some seriously hokey things in the board index, for example, and it has caused problems with custom themes and some mods - but because I can see the cause and effect (i.e. that SD does some hokey stuff, and the other mods and themes rely on assuming that the board index is untampered-with), I can mitigate it in SD itself by catering to those assumptions.

My point here, I guess, is that mods can be written with other mods in mind, if the author chooses to be careful about it.
Quote
That doesn't seem crazy.  That said, if you add a hook for every possible file edit, I promise you that you'll regret it later.  More on that later.
I never intended to write hooks for every single possible point. The reality is that you actually don't need to be that thorough. Since there's a separation, by design, between content processing and display, and everything is routed to $context, there's no overarching reason why you couldn't just throw a hook at the end of every action and make sure $context is available, plus anything that might be useful in the context of the action itself, and that would solve a great number of problems before you start. (It would also be quite hacky, I think, but it would certainly solve some of the issues.)
Quote
This is a fairly easy argument to refute.  I'm going to keep it brief because it's getting late, and I need to get some sleep, but:
Not going to go into detail, because I knew it was a fairly weak argument to begin with, but the question does throw up some interesting permutations, as you go on to expand with.

I never wrote a driver or made some of the changes you did, so yes, I hit the apps side rather than the mods side. Yes, I also knew about the A-vs-W stuff as I started out writing on WinNT 4 and made them work on Win98 and WinXP as well. Really, the point being made was that if we can do some of this stuff in other ecosystems, it should be possible to do some of it in the Wedge ecosystem, and it was more a comment to encourage people to stop and think for a moment.

Mods in the current ecosystem very broadly fall into two categories: mods that add new behaviour (which are ultimately more like apps) and mods that modify existing behaviour, and I've written my share of both for SMF.

A lot of the very popular mods do fall into the first category, and ideally I want it to be as painless as possible for them to be developed, because if I can get that to be the case (like supporting something like SimpleDesk), I can then focus on how to improve the end to end experience for the modifying-existing-behaviour case too. It's all parts of the same problem, and there isn't a one size fits all solution for it. I had actually debated leaving just hooks in the core and making file editing be managed through an official add-on, that could essentially be a dependency for mods that actually needed it. (This sort of behaviour is not unheard of even in the forum ecosystem. Whether it's desirable is another matter entirely.)
Quote
A number of reasons (although if there's enough semantic hook detection, this can be mitigated.)

A well developed mod will be shipped as one version, even if there are multiple popular current branches of Wedge currently being used.  In some fashion, different hooks need to be installed potentially for different versions - consider that Wedge 2.0 adds a new hook that this mod wants to use, but in Wedge 1.x, it needs to use other hooks (or file edit the hook in, for BC.)
You can certainly do that. I've done it myself, writing mods for both the 1.x and 2.0 branches of SMF and bundling them in the same package. But it's hard work because of the nature of changes in SMF between the two branches and in all honesty, I'd personally rather have not bothered with the dual packaging. (In fact, I shied away from making mods for both branches at once, simply because invariably I had to write it twice, because everything was different, most importantly $smcFunc vs db_query)

Users, generally, don't seem to have a problem with mods being in separate packages for different versions provided it's made clear to them what package is what, and the concept behind my hook detection methodology would mean that Wedge's main core would know what hooks it had available to use, and thus what hooks a given mod could use, while the main site would know all the hooks in every version.

As I mentioned somewhere, not sure if it was public, there was very much an awareness in the design about freezing the API, so that if a hook changed its structure, it would no longer exist in the previous form. That's no different to saying "versions 1, 2, 3 support this, version 4 does not", just you're not relying on a human doing the legwork in stating it in the package.

It was suggested before that SMF's mod site could attempt to perform installations on different versions and see if the file edits were successful, in a similar manner, but that it would ultimately cause more problems than it solved if other behaviour were broken - the plan, then, would be to make it so hooks generally wouldn't change between versions unless absolutely necessary - then break it in a non BC manner.

I would point out that it is our intention not just to throw out a release and then declare it feature frozen for the life of that branch. We always planned to handle it iteratively, in a kaizen-style of development whereby each version adds something as well as just bug fixes, some method of improving how we do what we do - instead of just giving users a 'this version just fixes some bugs' reason to update (which is a push factor), we want to give them some pull factors too.
Quote
This can be mitigated by some sort of hook detection, but this has its own set of problems.  One option is to run plugin init code on every page view, but this has performance problems with many mods.  Another is to re-run hook init logic for every different version number internally and/or whenever plugins are installed/removed, so the logic can be updated and cached.  This has its own complications, mostly that it isn't simple to write.
I'd already written a prototype of it, run on install/remove, and a much more naive, limited version already exists in SimpleDesk's plugin manager.
Quote
I don't know the specifics, but it looks like it was a file-uploaded-but-shouldn't-have-been-allowed type of issue, or maybe a CSRF.  Assuming this is true, and attachments or cache are writable, you're probably screwed no matter what.
It was a file being uploaded that was able to be executed. Which then tries to infect any PHP file it can modify.
Quote
I don't think users like dealing with order-of-installation issues, or contention issues, or any of those things.  I also don't think they like dealing with manual edits or uploads, incompatibilities, or etc. either.  Users also don't want indirect problems like core development slowdown or not being able to upgrade because a new version has different hooks.

Trying to think only of the user often ends up ignoring a significant part of their concern.  Best to think of everyone and only prioritize the users where possible, IMHO.

That said, I know that you care about the users already from past conversations, and that's a very good thing.  I'm not knocking that at all.
Order of installation is an issue that, really, only comes about because of multiple mods doing file edits in contentious areas - and specifically because one mod makes a broader selection than it needs to. The contentious areas can be removed with hooks, meaning that with very few exceptions, order of installation is a non issue.

(There is one exception I'm aware of, where there's a mod that is explicitly hook only, even in SMF, and it checks periodically to make sure that for one particular hook, it is always called last. But such things do not strike me as common with properly written mods using hooks.)

From a plugin perspective, there are two groups of user I have to consider, and only two. Yes, other users need to be considered for other things, but purely for plugins and their related infrastructure, I need to consider mod developers and mod consumers, aka forum admins.

The main concerns from mod consumers are that mods work with given versions of the software, that if they pull down an update, that their mods will continue to work (or at the very least, safely stop working, pending an update from their authors), and that mods work with as little fuss as possible, which generally means few file edits and working on as many themes as possible without any hassle.

Most mod consumers seem to understand that some mods will require manual work if they are particularly complex, but do not relish the frequency of manual installation that mods seem to need, especially if there are file permissions issues, or custom themes. There is almost a sub-industry lurking in SMF of people who will perform mod installs for people for money, usually only a small amount, but the fact that people are prepared to pay others to install mods does bother me slightly.

On the other hand, mod developers do seem to like the accessibility into SMF's internals, but most of them do not like the level of support requirement, namely having to update the listing for given versions (because even if a mod package explicitly lists 1.1.* as a working version number, the listing on the mod site won't, and users will *definitely* ask if a given mod for 1.1.x will work on 1.1.y)

The biggest problem for a long time was the lack of tools given to mod authors for SMF - there are now tools available for doing mods that work without much/any hassle, and minimising the amount of hassle there is on other mods. SimpleDesk is no different, and about half of the edits it used to make (that were low-maintenance) now become no-maintenance because they're no longer edits.

There are naturally downsides to this: the implementation method of SMF's hooks is a little bit narrow-minded, and there aren't enough hooks in some of the areas that would be useful to have hooks. Almost none of the admin panel has any hooks, only the menu really does, and the 'Modification Settings' entry in the menu, which is fine if you're doing huge mods that add new menu items or new menus entirely, or one-shot settings, but anything in the middle isn't really catered for unless you abuse the tools given to you.

And while I'm bound to draw criticism for the above comment, the simple fact is that: the idea of expanding the hooks is good, I welcomed the change because compared to what there was, it was a massive improvement. But it did lack one really big change that Nao added almost straightaway to Wedge: the ability for a hook to load a file when necessary. You want to use a hook in SMF... fine, just use one of the few points you actually get to load a file, which means you invariably load files on init rather than where it would be useful to load them.

That, and the fact most mod authors simply do not understand how to make the hooks work properly, because the only documentation on the hooks was either written by Orstio way back or by me for 2.0 RC3 - which doesn't include the multi-calling ability, or indeed the method by which you now add callees to hooks.
Quote
This was just one of the historic "bad decisions" we made.  This came up several times while we were working on the feature.  I noticed it and considered it, we talked in the dev team about it, and the team discussed it.  But usually briefly, and the answer was always "ah, it's fine to reinstall every time."
It's not really great for users. Most of them will understand, to a point, once you've beaten them over the head, but half the time they won't understand off the bat, especially if their mods won't reinstall properly (or worse, as happened during more than one SMF RC upgrade, the mods continued to be listed as installed when they weren't).

There is, buried in the depths of the upgrader code, some facilities for this but I don't think they're enabled and even if they are, I don't think they work properly.
Quote
At one point, someone had proposed a more robust system, that tracked exactly what to do, installation order if necessary, and did a dry run unapplying, updating, and reapplying, and told you which mods weren't compatible that way.  I don't remember how it totally went, but we didn't do it because we figured the effort wasn't worth it.
That would be a major step up from where SMF is now, but honestly that's not a road I want to go down if I can help it. I want to make it as painless for admins as possible, even to the point where if something breaks, it can always be unbroken again with as little effort for them as possible: most admins are not that technically inclined (much as I find the idea weird: why run something without learning a bit more about it?), and most will simply ask for help rather than anything else.

Here's where it gets weird, though: it never seems to be a mod author's fault that mods have the hurdles they do. For the very most part, problems with mod installation always seems to be SMF's fault in the user's mind, which leads to SMF getting unfair comments that it doesn't deserve.
Quote
Presumably, not a ton of code has changed between SMF 2.0 RC5 and SMF 2.0, right?  So in theory, this sounds right.  I'm not sure what it means to check the compatibility; from context, I assume this is some manual process?
Users should check that mods have been updated for 2.0 by looking at the mod's page. Especially since each RC has brought some interesting changes with it (as it happens, there are behavioural changes between RC5 and final that some mods will have problems with)

Oh, and before I forget, as it's relevant. You asked what version-emulate was. In 1.1.x, version_emulate was a parameter to add to the URL while in the package manager to override the internal SMF version, thus you could install a package that only listed 1.1.13 in it, while you were running 1.1.14, for example. SMF 2.0 took it further and put a UI in the package manager itself that let you type in this version you wanted to use. (As it happens, I wrote a UI for the 1.1.x version as a drop-down to ease the process).

You can, then, attempt to install any mod on 2.0 without much fuss.
Quote
These are a common concept in integrations now, and something I strongly recommend for Wedge.  I would imagine that file edits might be a permission.
Incidentally that's actually where I was going with my own package stuff. The manifest declares what hooks it uses, plus optionally things like obscure PHP functions from extensions, PHP version, MySQL version, that sort of thing.

I hadn't really thought of making file edits a permission in that respect, because I don't like the idea - I am only too aware how users are becoming 'trained' to accept stuff. That said, I guess it could be done, especially if it makes mod authors less inclined to do so where possible. It would probably be better than my app-wide solution at least.
Quote
I think that administrators can be made happy without having a rigid product.  Ultimately I see both extremes as "unhappy administrators" just for different reasons.
I'd rather not have unhappy users if possible. I don't really see us as being that rigid by doing this, either, but I know full well that I'm biased towards this approach, but I'm also aware that I'm going to end up writing a lot of mods for functionality not in core that other systems have.
Quote
Although I value a lot SMF's flexibility of being able to change almost every imaginable thing in the system I just love mods like SimpleDesk (which is a very nice piece of software, congrats Arantor!) or AEVA, the way they install, uninstall and upgrade without issues with the core and then the amazing gui and amount of freedom and features they provide inside the mod itself (which to me cover 99% of the aspects I would like to be able to customize in such a mod).
Interesting you should mention both of those. In both cases they qualify as 'big mods', but they both have to deal with certain things: most notably, they both find SMF's permissions system framework inadequate and quickly end up replacing it or augmenting it (SD uses absolutely none of SMF's permissions, Aeva only uses a few for very granular control), and they both make fairly minimal (but surgically precise) changes to SMF's own core and move everything into their own files and user areas, and as such are reasonably free of the constraints attached to smaller mods that embed themselves into SMF deeply.

That said, there are some integration-y bits in SD that bend the rules, and expectations.


---I think I got everything.---
Title: Re: Unknown's thoughts on Wedge
Post by: Dragooon on June 30th, 2011, 08:38 PM
As someone who just went through a LOT of hell, I gotta say I am with Arantor now. File edits are a pain to deal with, even if that means removing a lot of control, modders and admins will go through anything to get it to work and it really messes things up. Although it can only with if you have an advanced templating system like TOX-G, because normal PHP template hooks won't cut it. That, and standardizing data loading, SQL querying etc.
Title: Re: Unknown's thoughts on Wedge
Post by: Arantor on June 30th, 2011, 10:20 PM
Yes, there is a battle of opinions, but the core is relatively consistent: we all agree that there are problems with the current state of play, and that adding hooks will alleviate the very worst of those problems. Then, if we add other methods of extensibility, of which TOX-G really is one of the major investments, but with several other measures as well... things really take shape.

Consider: SMF is very extensible on a small scale but anything that doesn't conform has to really do the spade work itself. Aeva, Project Tools, SimpleDesk... what do all these have in common? (Plus, likely, elements within the portals) Answer: they all had to implement their own permissions systems, because SMF's permissions system allows for 'in a board' and 'not in a board' permissions, but nothing more configurable or flexible.

I can find you plenty more examples of that thinking throughout SMF, but that's not really my point: my point is that while SMF is extensible, it's extensible along certain directions and I'd like it to be more than that.

I don't think anyone here has any disagreements in the issues that there are, in terms of extending what's there. What we're disagreeing with are the different ways that we can extend it and how it can best be achieved.

Hooks aren't the answer to it on its own, and I never said or intimated it was. They're part of a bigger picture. File edits are another part of that picture, but I want to alter the composition to make it a much smaller part of the picture than it currently is, and I want to pick out new details.

I kind of get the impression that, for the most part, we all agree on what the picture should look like (a fine landscape) but some of us want to see a nice cottage, others a forest, some want more sky than land and so on. We all want a nice picture at the end, and while we might not all be perfectly happy with it at the end, hopefully the overall picture will be nice.

Right now we're arguing over how big the forest in the landscape is, or the size of the cottage. We're not arguing that the picture needs sky and land, and that it needs trees and maybe that cottage - only the relative sizes and the fine points.
Title: Re: Unknown's thoughts on Wedge
Post by: Nao on July 1st, 2011, 12:46 AM
Pete, what are you working on in Wedge these days? Thinking process only?

Cuz we need to review what's coming next... Even I am lost.
Title: Re: Unknown's thoughts on Wedge
Post by: Arantor on July 1st, 2011, 01:02 AM
The last few days I've been dealing with a family funeral, and I actually reverted everything I did because I felt very strongly that it was the wrong route. Right now I'm not 100% sure it is the right route any more.

:edit: Everything that's gone on the last few weeks (not just here but in real life too) has left me somewhat uncomfortable with my thought processes. I think I'm going to need to work on smaller stuff for a bit, until I get more settled :(
Title: Re: Unknown's thoughts on Wedge
Post by: Rustybarnacle on July 1st, 2011, 04:36 AM
Take care of yourself.  As much as everyone is excited about the projects that you are working on, like Wedge and SD, your life and mental health are far more important.
Title: Re: Unknown's thoughts on Wedge
Post by: Arantor on July 1st, 2011, 12:15 PM
*nods* It's like I've lost my confidence in myself to a degree :(

So this morning I took some time out to do some work on one of the SimpleDesk team mods that I worked on ages ago and had long since written some bug fixes for. While that sounds like it's counterproductive for Wedge, it really isn't because it's shown me yet more issues for extensibility in the framework of SMF, and ones that hooks won't solve. I'm not just referring to hooks in SMF that are missing, but issues that cannot be solved through hooks in the conventional sense.

They're things I want to be able to solve, and some of the side issues can be solved in other ways - it would help, for example, if the message index and display views weren't monolithic in nature. TOX-G will solve some of that but also so will breaking them up into manageable chunks (that can be manipulated in the subtemplate loader now)


Interestingly I realised today that my enthusiasm for writing plugins could be almost as dangerous as bundling everything in the core if improperly handled - there is a very important warning that I've sort of taken on board but not as thoroughly as perhaps I could.

Having more power in the core, and having stock modifications available does discourage people from creating their own - to a point. Having AeMe in the core does negate the need for other gallery modifications from being created. I don't necessarily see that as a bad thing: it means we can polish up and refine the integration between the two and make real use of AeMe's power outside of the gallery itself, and it's not like there were a lot of galleries for SMF - mostly because between SGL/SGP and AeMe, there really wasn't a need for another.

SimpleDesk is another similar scenario: I don't see anyone else ever writing another helpdesk for SMF - not only is it pretty niche, but I think I did enough of a good job with SD that another isn't needed unless SD is wholly unsuited to a given task.

But I find that's limited mostly to the 'new functionality' add-ons, not the 'modifying existing functionality' ones, I foresee there will always be new ways to do that, and people always wanting to do so. But I figure if I attack the most commonly requested mods, to deal with the general cases, it doesn't negate anyone else doing it, it just means that people can focus their attention on new things instead of finding existing things to rehash over and over, if that makes sense.
Title: Re: Unknown's thoughts on Wedge
Post by: [Unknown] on July 4th, 2011, 06:32 AM
Quote from Arantor on June 30th, 2011, 06:46 PM
It was mostly a statement in response to Unknown's question about upgrading from 2.0 RC5 to final being a full update (which it is, unless you're insane enough to go through and make the changes to each file by hand, as I did in Wedge's case)
Or try a diff between the two release trees, which probably wouldn't apply cleanly in most cases.

To me, that's more caused by the major changes.  In the case of SMF 2, if the API to make database queries, or all that string stuff, etc. changed between releases... you're screwed.  Doesn't matter if you're writing a plugin, widget, modification, or even a poem.  It means your stuff is wrong and has to be rewritten now, no matter what.
Quote from Arantor on June 30th, 2011, 06:46 PM
Ah, that means I've been reading between the wrong lines.
I try to mean what I say and say what I mean.  If I ever do otherwise, please call me on it.  I find reading between lines to be an dangerous pass-time at best, so I try not to make people do it.
Quote from Arantor on June 30th, 2011, 06:46 PM
Yes, that's the plan. I look to SimpleDesk on this one: there are some places I do actually do template edits in SD 2.0
In contrast, because of themes, I think template edits are pretty much "always wrong."  I tried to solve this as categorically as possible in TOX-G, even allowing alters to completely replace an existing template.  I realize file alterations might still be needed in some cases, but I'm hoping that the average user will have zero template file edits, because it pretty much destroys theming.

I also realize a good majority of mods are based on themes, which as I said, can hopefully all be done in a "clean" way.
Quote from Arantor on June 30th, 2011, 06:46 PM
the track-IP screen or the manage-attachments screen unless they had very, very good reason (and SD does, in both cases) - and since they are uncommon templates, I'd never had a conflict.
Hmm.  I retract my statement only a few lines above this.

In this case, file edits don't seem horrible at all.  While I still think themes should be able to modify administrative areas, if a couple of templates can be used to control generate look (without forcing an exact HTML structure, which is what I always didn't want to do), then I don't think there's generally any good reason for a theme ever to change the meat of an administrative section.

That said, if they used templates cleanly, it might possibly be avoidable there too.
Quote from Arantor on June 30th, 2011, 06:46 PM
Not all things are expressly hook points as we normally think of them.
Well, in terms of TOX-G, templates are "hooks" as well.  There are many cases of these.  All have costs, but most are minimal.  A css class is not too expensive, nor is the function call incurred at runtime for (defined only, altered or not) TOX-G templates, especially since this call is static and can be optimized by e.g. an accelerator (unlike dynamic hooks in code, which typically use call_user_func_array or etc.)

Also as I mentioned before, using Exceptions can add more hooks, because it adds the possibility of wrapping the HTML output of SMF/Wedge/etc. in another software (as long as exit is done in cases of file or xml output.)  In a way, this is a hook as well.

Another place for hooks (but this has a high version requirement as a cost) is e.g. database functions and views.  They don't actually allow renaming or hooking easily, but potentially they could be used for hooks (e.g. instead of something liek query_see_board.)
Quote from Arantor on June 30th, 2011, 06:46 PM
My point here, I guess, is that mods can be written with other mods in mind, if the author chooses to be careful about it.
Well, I agree with designing in a way that this is not necessary to think about.  Just like security; anything that can be made automatic is better that way, as long as it doesn't have other downsides.
Quote from Arantor on June 30th, 2011, 06:46 PM
(It would also be quite hacky, I think, but it would certainly solve some of the issues.)
Sure.  Although that can't do everything.  Imagine if the recycle bin functionality were to be made a mod (in fact, I'm fairly sure it was at first.)
Quote from Arantor on June 30th, 2011, 06:46 PM
it should be possible to do some of it in the Wedge ecosystem, and it was more a comment to encourage people to stop and think for a moment.
Well, possible and practical aren't always best buds.  In this case, I suspect Microsoft has a couple more employees to put on the problem than probably Wedge ever will, which was the point I was trying to make.
Quote from Arantor on June 30th, 2011, 06:46 PM
(This sort of behaviour is not unheard of even in the forum ecosystem. Whether it's desirable is another matter entirely.)
Well, I agree the current package manager leaves a lot to be desired.  Separating it isn't necessarily a bad thing, but leaving it alone without improvements might be.
Quote from Arantor on June 30th, 2011, 06:46 PM
But it's hard work because of the nature of changes in SMF between the two branches and in all honesty, I'd personally rather have not bothered with the dual packaging. (In fact, I shied away from making mods for both branches at once, simply because invariably I had to write it twice, because everything was different, most importantly $smcFunc vs db_query)
Well, again, I feel this was a separate problem.
Quote from Arantor on June 30th, 2011, 06:46 PM
Users, generally, don't seem to have a problem with mods being in separate packages for different versions
Hmm, users I've talked to (before and since) generally seem annoyed by it, although perhaps more often than not it's because they can't find one for their version.
Quote from Arantor on June 30th, 2011, 06:46 PM
what hooks it had available to use, and thus what hooks a given mod could use, while the main site would know all the hooks in every version.
Just because a hook exists doesn't necessarily mean everything.  What if you release a version with a broken hook (accidentally)?  Do you consider this a critical update, and release a patch soon after (as with a security hole) or do you let it sit for the next usual release (potentially causing confusion)?
Quote from Arantor on June 30th, 2011, 06:46 PM
It was suggested before that SMF's mod site could attempt to perform installations on different versions and see if the file edits were successful
That sounds possible but like a potentially heavy hammer.  That said, separating the package manager out a bit (not necessarily completely) and making it run via command line would probably improve things there and elsewhere:

  - automation becomes much easier.
  - admins who don't want to type in a sftp password or anything can do it through cli.
  - less concern about "apache died in the middle of the operation" issues.
  - obviously it would still need to be able to run from web.

If that were the case, the mod site upon upload could potentially run:

php /home/smf/tools/packman.php install --dry-run --install=/home/smf/versions/smf_2/2.0/

So while I still think the concept of running against every version is overkill, the concept itself may not be awful, even to at least verify the current version works.  In fact, even with hooks this might be an easier method than keeping a (probably out of date) list of hooks, especially if there are many.

I know near the tail end, I started to make the status tools and upgrader, etc. cli friendly.  Can't recall how many I got to.
Quote from Arantor on June 30th, 2011, 06:46 PM
I would point out that it is our intention not just to throw out a release and then declare it feature frozen for the life of that branch. We always planned to handle it iteratively, in a kaizen-style of development whereby each version adds something as well as just bug fixes, some method of improving how we do what we do - instead of just giving users a 'this version just fixes some bugs' reason to update (which is a push factor), we want to give them some pull factors too.
Then you need to at least do code review.  Something has to happen or eventually, things will be changed wrongly in that model.  AFAIK, Firefox (now) and Chrome have a lot of red tape involved in the process so that it can happen fast.
Quote from Arantor on June 30th, 2011, 06:46 PM
It was a file being uploaded that was able to be executed. Which then tries to infect any PHP file it can modify.
On "secure" suexec installations this would be all files, so you're screwed in this case.  In insecure nobody installations, this could potentially be many files or even other accounts on the server.  So you're screwed that way too, even without the package manager needing things writable.
Quote from Arantor on June 30th, 2011, 06:46 PM
Order of installation is an issue that, really, only comes about because of multiple mods doing file edits in contentious areas
Not true.  Two plugins hooking the same hook can also cause issues, e.g. if one processes out something and the other one needs it for some other reason.  It's rare, but at least with file edits, they fail rather than have weird edge-casey problems.
Quote from Arantor on June 30th, 2011, 06:46 PM
people are prepared to pay others to install mods does bother me slightly.
People also pay for upgrades and installs.  I usually did them (or tried to) for free, but only when I had time.  At work, we are paid to install other software - like vBulletin or osCommerce or even Bugzilla.  Even if they are easy to install, sometimes people want someone else to deal with it and polish it up.

That doesn't seem wrong to me, in any case.  That said, if it's becoming necessary, that seems bad.
Quote from Arantor on June 30th, 2011, 06:46 PM
they're no longer edits.
Well, unless major changes happen again, as did with SMF 2.0.  What if they separate out the core, and now all the syntax for everything has to change again?  Are these "maintenance" areas really big problems between e.g. 1.1.1 and 1.1.2, etc.?
Quote from Arantor on June 30th, 2011, 06:46 PM
the ability for a hook to load a file when necessary.
I've not looked at SMF or Wedge's hooks, but how can this not be possible?  Doesn't a hook run code?  Can't code include files?
Quote from Arantor on June 30th, 2011, 06:46 PM
There is, buried in the depths of the upgrader code, some facilities for this but I don't think they're enabled and even if they are, I don't think they work properly.
Yeah, I know it was there, initially it wiped out installed.list IIRC.  I think we moved to a database to remove the requirement of that file being writable, and may never have fully moved everything over.
Quote from Arantor on June 30th, 2011, 06:46 PM
(much as I find the idea weird: why run something without learning a bit more about it?)
How much do you know about the internals of PHP?  Do you know what the zval cache is?  And even if you probably do, do you think most PHP programmers do?  I don't necessarily think it is weird, it is compartmentalizing.  Definitely it's better to learn about it, but time is required.
Quote from Arantor on June 30th, 2011, 06:46 PM
Users should check that mods have been updated for 2.0 by looking at the mod's page. Especially since each RC has brought some interesting changes with it (as it happens, there are behavioural changes between RC5 and final that some mods will have problems with)
Which means, in other words, that they were betas.  And if the last RC and the final and major behavioral changes (which I gather it did), then basically a release candidate was never made.

I'm sure I made mistakes in this area too, although I think the general rule was that we branched the next release when we RC'd, so theoretically the major changes were happening in the next release at that point.
Quote from Arantor on June 30th, 2011, 06:46 PM
Oh, and before I forget, as it's relevant. You asked what version-emulate was.
This sounds like a bad idea.  I would rather just say "hey, this version says it won't work, want to try it anyway?"  I even thought it did that.... but I guess it probably doesn't.
Quote from Arantor on June 30th, 2011, 06:46 PM
I am only too aware how users are becoming 'trained' to accept stuff.
You can change whether you ask, though, especially depending on settings.  For example, for most permissions Chrome never asks.  They may ask in the future (without requiring extensions to change anything) if they need to.  This gives Chrome all the options without a lot of work from extension authors.
Quote from Dragooon on June 30th, 2011, 08:38 PM
That, and standardizing data loading, SQL querying etc.
Which if done wrong (as many people do) can make optimizations extremely painful to deal with...
Quote from Arantor on June 30th, 2011, 10:20 PM
SMF's permissions system allows for 'in a board' and 'not in a board' permissions, but nothing more configurable or flexible.
This always felt like a hack to me, actually, and I never felt completely comfortable with the way board specific permissions kinda shook out.  They still confuse me, which is a bad sign.
Quote from Arantor on June 30th, 2011, 10:20 PM
Right now we're arguing over how big the forest in the landscape is, or the size of the cottage. We're not arguing that the picture needs sky and land, and that it needs trees and maybe that cottage - only the relative sizes and the fine points.
At least we're not (or at least I hope I'm not) arguing about the color of the bikeshed.
Quote from Arantor on July 1st, 2011, 12:15 PM
but also so will breaking them up into manageable chunks (that can be manipulated in the subtemplate loader now)
Does SMF's system yet allow for multiple subtemplates to be used on the same page?  Example: "poll", "poll", "calendar", "post_list"?  I think I mentioned on SMF I have since moved to this system (and TOX-G uses it too.)
Quote from Arantor on June 30th, 2011, 10:20 PM
SimpleDesk is another similar scenario: I don't see anyone else ever writing another helpdesk for SMF - not only is it pretty niche, but I think I did enough of a good job with SD that another isn't needed unless SD is wholly unsuited to a given task.
Actually, a reason not to have things in the core also is attack surface.  From a security perspective, I want to remove the calendar from (at least my own installs of) SMF because I don't use it, and it doesn't have a small SLOC.  The more code, the more potential bugs, and the more potential security flaws.

That's why I've always wanted the calendar to be a "bundled mod."  It's also part of the reason I like file edits, to a degree, because having code that isn't run when a setting off is nice, but having code that can't even be run unless I twiddle the file permissions is nicer.

But, I know that most people are not so "don't even use their real name online" paranoid as me when it comes to privacy and security.
Quote from Arantor on June 30th, 2011, 10:20 PM
But I find that's limited mostly to the 'new functionality' add-ons, not the 'modifying existing functionality' ones, I foresee there will always be new ways to do that, and people always wanting to do so. But I figure if I attack the most commonly requested mods, to deal with the general cases, it doesn't negate anyone else doing it, it just means that people can focus their attention on new things instead of finding existing things to rehash over and over, if that makes sense.
Sure, except it can narrow the mindset.  For example, consider the general concept of lesscss:

First, the code was written to be "post-processed."  This is nice, and the templates are easy, but it makes development kinda slow, especially if you don't have ruby set up in your webserver.

Then came along node.js, and lesscss was rewritten in js.  The same code now runs in browser (for development) or on dist (for post-processing prior to production.)

Whereas rewrites are often bad things (as noted with YaBB SE -> SMF was a gradual rewrite, not a from scratch one), in this case a context change was pretty much required.  The Ruby one made sense, but is now deprecated and replaced by the js one.

Now consider if Apache had released, as part of the Apache distribution, a "less" module and used the Ruby code (or even ported it to C) to serve the converted CSS through Apache.  Even though the js solution is better (because it works everywhere, and combines well with minification), it probably wouldn't have happened, and people would be complaining right now that there's no nginx version of less.

-[Unknown]
Title: Re: Unknown's thoughts on Wedge
Post by: live627 on July 4th, 2011, 06:56 AM
Quote
I've not looked at SMF or Wedge's hooks, but how can this not be possible?  Doesn't a hook run code?  Can't code include files?
Yes they do. But here's the thing. Although hooks do run code as you speculated, they don;t include files. SMF has three hooks designed for this purpose: one in reloadSettings(), one in loadTheme(), and one in the admin loader. All Wedge hooks use an extra parameter to load a file, in add_hook IIRC.

So then what good is a hook if no external files become included?
Title: Re: Unknown's thoughts on Wedge
Post by: [Unknown] on July 4th, 2011, 07:01 AM
Ah, I see.  Well, there's ups and downs of that.  A reasonably easy workaround is to include a (small) file on loadSettings or what have you, and then from there load additional file(s) as necessary.  This won't have a huge perf impact.  But yes, specifying a file makes more sense.

-[Unknown]
Title: Re: Unknown's thoughts on Wedge
Post by: Arantor on July 4th, 2011, 08:41 AM
There's a lot of stuff in there for me to digest, but what live is saying is that you have to include a file every single runtime, or everywhere in the admin panel in order for it to be called. While that might not be bad if you have a few things that run every page, it's a bit excessive.

You have to load a file to add an action, for example, which defeats the nature of the action loader loading other files.
Title: Re: Unknown's thoughts on Wedge
Post by: Arantor on July 4th, 2011, 10:02 AM
Quote
Or try a diff between the two release trees, which probably wouldn't apply cleanly in most cases.
If you don't have any modifications, of course, this isn't a problem. The only trouble is, the diff is enormous since the RC5->final patch modified every single PHP without exception.
Quote
It means your stuff is wrong and has to be rewritten now, no matter what.
Yes, if the API changes in some fashion. That's the single biggest factor in migrating SMF 1.1.x mods to SMF 2.0, in fact.
Quote
then I don't think there's generally any good reason for a theme ever to change the meat of an administrative section.
Let me explain what exactly my edits did, and I'll let you judge for yourself. FWIW, I'm of the view that these are acceptable, not necessarily desirable.

I just checked, there are three template edits being made in SimpleDesk 2.0:
* manage attachments
* package manager
* track IP

Manage Attachments is one of those necessary edits. For a variety of reasons, we had SimpleDesk take SMF's attachments and modify the core code, specifically so that if attachments worked normally, SD's would too. All that we do is store the SD-specific metadata in its own table, and don't attach a topic id to the normal attachments (and yes, I did account for that in the maintenance... I think I did, anyway... have to check that now, it's been a year since I wrote it)

All the template edit has to do is add to the 'Browse attachments' / 'Browse thumbnails' links in the browse files area, to add 'Browse helpdesk attachments' / 'Browse helpdesk thumbnails'. Since it's injecting two links directly into the template, I wasn't uncomfortable with it.

Package Manager... well, SD has a form of plugin manager (which is to say, it has an interface for managing hooks that other things might use). For convenience I used SMF's package manager to get the plugins onto the server and files in the right places, then SD's code deals with activation and making them work.

Since that was already the case, I moved SD plugins into their own block of the package manager which is a template edit to expand. (Were I in charge of this, I wouldn't have it as a template edit, I wouldn't require one, I'd have the setup of the $context variables specifically to avoid needing any kind of edit, but that's me.)

There are only a handful of mods for the package manager, one of which I wrote, and I knew full well that it wouldn't be a problem to integrate this in with it.

Lastly, track IP. Underneath the 'list of posts from this IP', we add 'list of helpdesk posts from this IP'. It's not commonly modified, and it's just another call to the generic list template, really, so that's a not a problem either - it's just that if the template weren't a single monolith but a list of templates, it would be trivial to add another.
Quote
but potentially they could be used for hooks (e.g. instead of something liek query_see_board.)
I actually made is substantially easier for a mod to declare such things, and add them to the query; it's now possible to define your own without having to modify the DB code itself - which is the sort of thing I meant when I said that hooks weren't the only thing to contend with.
Quote
Well, I agree with designing in a way that this is not necessary to think about.  Just like security; anything that can be made automatic is better that way, as long as it doesn't have other downsides
That's really what I'm trying to do, is to make it possible to automate as much as possible without having to make mod authors and/or mod users deal with it.
Quote
Sure.  Although that can't do everything.  Imagine if the recycle bin functionality were to be made a mod (in fact, I'm fairly sure it was at first.)
Something like that would have to be done as manual edits, I don't think there's any way around that - but on the other hand, something like that should be in the core anyway.
Quote
Then you need to at least do code review.
There is an informal code review going on with commits.
Quote
So you're screwed that way too, even without the package manager needing things writable.
*nods* But it was still hitting and enveloping instances that weren't running suexec, too, because of elevated permissions. Most people do not modify their permissions back after the event, because it's convenient for them not to have to do so.
Quote
Not true.  Two plugins hooking the same hook can also cause issues
Sure they can, but it's far more common when it's file editing going on. Looking at the sorts of stuff that was emerging in SMF's ecosystem, the vast majority was additive rather than anything else, such that the order of installation for most things wouldn't be an issue at all in most cases. And usually, where order of installation is important for some reason, it's either documented by the mod author (who can also deal with support), or they deal with it in the mod itself (e.g. SlammedDime's SimpleSEF periodically makes sure it is the last hook called - though I recognise that it's possible a second mod will attempt to do the same and cause issues that way, but I gotta say that's very much an edge case there, order of execution is not that much of an issue for the *majority* of mods)
Quote
That doesn't seem wrong to me, in any case.  That said, if it's becoming necessary, that seems bad.
I don't think it's becoming necessary. But it is becoming far more common, that people seem to feel it is becoming more necessary because there is a hurdle for them to overcome. The majority of admins want it to just work and become very upset/flustered when it doesn't, especially when it goes wrong and really breaks something.
Quote
Well, unless major changes happen again, as did with SMF 2.0.  What if they separate out the core, and now all the syntax for everything has to change again?  Are these "maintenance" areas really big problems between e.g. 1.1.1 and 1.1.2, etc.?
When you have any big jump, that's going to be expected. With a big jump you expect to have to do stuff like that. But between small version jumps, you shouldn't have to do much, if anything. Yet there are a great many mods that interfere with version updates and vice versa.

SMF is really a bad case to discuss this sort of thing. SimpleDesk now has less maintenance and editing in the really key areas - and they're the key areas that are high-maintenance: actions, admin menu, permissions, plus it has less maintenance by using a hook for one of the display template functions too.

Yes, when 2.1 rolls around it will need to be modified, of course. But for the meantime I can rest easy in that mods and updates shouldn't affect those parts of SimpleDesk - at all.

If anything, it's going to be less hassle than developing alongside the RCs was, because each RC brought new things with it that weren't bug fixes (RC3, 4, 5 and final all brought style specific changes, RC4, 5 and final all brought hook related changes)
Quote
Yeah, I know it was there, initially it wiped out installed.list IIRC.  I think we moved to a database to remove the requirement of that file being writable, and may never have fully moved everything over.
That's the problem: it's all in the database, and the upgrader doesn't deal with it properly. The file is still present, though, it just contains the timestamp of the last install. Quite *why* it does that, I have no idea.
Quote
Which means, in other words, that they were betas.  And if the last RC and the final and major behavioral changes (which I gather it did), then basically a release candidate was never made.
That's pretty much the story of 2.0 from RC1 onwards. Each release brought changes that were ultimately non trivial.
Quote
This sounds like a bad idea.  I would rather just say "hey, this version says it won't work, want to try it anyway?"  I even thought it did that.... but I guess it probably doesn't.
You can't do it that way: remember we talked about multiple versions being handled in the same package? There's your reason not to do it that way. Imagine you have a mod that states it supports 1.1.13 and 2.0 RC5, and you're on 1.1.14. Which set of instructions should it use as a 'default' fallback?
Quote
This always felt like a hack to me, actually, and I never felt completely comfortable with the way board specific permissions kinda shook out.  They still confuse me, which is a bad sign.
Board permissions confuse a lot of people and 2.0's move to using profiles for boards is even more confusing. I know the entire setup needs to change but I'm not yet sure which way to go for the best.
Quote
At least we're not (or at least I hope I'm not) arguing about the color of the bikeshed.
I don't think we are, and that's not what I meant by my comment either. We agree there are issues with the current state of play, and we agree on how some of those issues may be resolved, and disagree on others - but really, our ground is not that uncommon, we're seeing the same issues with different coloured glasses. You're coming at it from your point of view, wherein maintenance and bugfixes - and practical measures that apply - are more important, while I'm coming from trying to make it as easy to use and possible for users, to minimise their hassle. Call it glass-half-full vs glass-half-empty at this point, because that's what it is, really.
Quote
Does SMF's system yet allow for multiple subtemplates to be used on the same page?  Example: "poll", "poll", "calendar", "post_list"?  I think I mentioned on SMF I have since moved to this system (and TOX-G uses it too.)
No, it doesn't. It can do template layers and a single inner-most template. Wedge does not have that limitation and we already use it in this fashion in a few places - though not nearly enough.
Quote
Actually, a reason not to have things in the core also is attack surface.
I can see that as an argument, it's entirely valid. And to your last point here in particular about file permissions... most users really do not want to have to do that. They want it to work as simply and cleanly as possible - and juggling file permissions is not part of that, IMHO.

From my perspective, the calendar as it stands is not that useful, so having it in core is not necessarily the smartest move, but if it were to be more useful, there would be more reason for it to be present.
Quote
Sure, except it can narrow the mindset.
I don't think there's any way to avoid that, though. Every time someone writes some code and releases it, it adds to the total substance of what's available - and every time that happens, there's one or more people out there who won't roll their own version of the same. From my POV, I see it as priming the pump for the most part, because I know others out there will think of ways to expand on what we come up with, and I know I won't be writing every possible permutation of mod either, so others who want it differently will invariably come up with their own spin on it.
Title: Re: Unknown's thoughts on Wedge
Post by: [Unknown] on July 4th, 2011, 11:11 AM
Quote from Arantor on July 4th, 2011, 10:02 AM
Let me explain what exactly my edits did, and I'll let you judge for yourself. FWIW, I'm of the view that these are acceptable, not necessarily desirable.
I think they're fine an all "hookable" in some fashion, although whether hooks would necessarily be forethought for all these areas is uncertain.  Th only area I see a theme potentially wanting to touch is the IP one, and probably not.
Quote from Arantor on July 4th, 2011, 10:02 AM
(and yes, I did account for that in the maintenance... I think I did, anyway... have to check that now, it's been a year since I wrote it)
Ah, good.  While I think no one uses that feature (at least they didn't used to), I think it's a good feature.  It came from YaBB SE and probably even YaBB, originally.
Quote from Arantor on July 4th, 2011, 10:02 AM
Something like that would have to be done as manual edits, I don't think there's any way around that - but on the other hand, something like that should be in the core anyway.
Still don't agree that the core should have a working kitchen sink that churns out boiling hot and cold water, but I do agree with the decisions that led to that particular mod being integrated (I didn't do that one but liked it after the fact.)  I think it was a popular YaBB SE mod.
Quote from Arantor on July 4th, 2011, 10:02 AM
(e.g. SlammedDime's SimpleSEF periodically makes sure it is the last hook called - though I recognise that it's possible a second mod will attempt to do the same and cause issues that way, but I gotta say that's very much an edge case there, order of execution is not that much of an issue for the *majority* of mods)
Well, edge cases are important.  Even if just knowing about them and documenting them.  People are professionals not because they don't make mistakes, but because they prepare for them in advance.  I'd rather know what can go wrong and know when it goes wrong than just be confused.

In this case, I think I've seen before a "hook weight" where you can basically say "I want to be first", "I want to be last" and sometimes even "I don't care [so put me in the middle]."  Even DOM events work in this way, with capture and bubble phases.

In practice, most people (especially people using jQuery, which likes to rename everything) only use bubbling.  But the DOM has both models(http://www.quirksmode.org/js/events_order.html).  AFAIK, no one has proposed taking it out even though almost no one uses capturing (the "I want to be first" one.)  In fact, jQuery doesn't even expose an interface for capturing(http://api.jquery.com/bind/), neither does Prototype(http://www.prototypejs.org/api/event#method-observe), nor Dojo(http://dojotoolkit.org/reference-guide/quickstart/events.html).  Basically only Closure does(http://code.google.com/closure/library/docs/events_tutorial.html), and no one uses it.

Of course, it doesn't help that IE doesn't support capturing.

Still, with some people going on the warpath on things like XHTML that no one uses or uses properly, because IE doesn't support them anyway, and wanting to remove them from the web, capturing has been left untouched.  Because it is necessary, even if only 1% of the time.
Quote from Arantor on July 4th, 2011, 10:02 AM
Yet there are a great many mods that interfere with version updates and vice versa.
Well, I don't remember the minor version updates being that major.  A mod has to touch, what, like less than 6% of the code base at most, on average?  It's surprising to me if the majority of minor version updates interfere with mods (not because they interfere with each other, but the actual updated parts.)

For contention areas, like new permissions, yes... there's really potentially no way around those without hooks.  That said, in most of my mods, rather than adding an index to an array, I'd add code afterward that would do e.g. $actionArray['x'] = array('y', 'z');.  While "ruining" the style, this didn't ever break and my mods were fairly low maintenance.

In fact, I can't remember ever having to make major changes to my wikilinks mod, for example.

So my point is that it shouldn't be that there are "high maintenance" areas where it's hard.  Those areas, if they exist, should certainly be hooks.  I know this was something, when I was around, we just hadn't gotten to yet.
Quote from Arantor on July 4th, 2011, 10:02 AM
That's the problem: it's all in the database, and the upgrader doesn't deal with it properly. The file is still present, though, it just contains the timestamp of the last install. Quite *why* it does that, I have no idea.
Oh, I remember.  Originally we set out to move to the DB and that was it.  Then we got concerned about the issue of someone uploading an upgrade package, and we wanted the installed.list in there for some reason.  I can't remember the details.
Quote from Arantor on July 4th, 2011, 10:02 AM
You can't do it that way: remember we talked about multiple versions being handled in the same package? There's your reason not to do it that way. Imagine you have a mod that states it supports 1.1.13 and 2.0 RC5, and you're on 1.1.14. Which set of instructions should it use as a 'default' fallback?
Well, you can pick the one that is most similar.  Starts with the most same characters, or matches the "lower than this" check but not "higher", or else matches the "higher" and is the lowest.  I don't see the point of picking a specific version to emulate when it seems as if the software can figure this out itself.

Especially when I do expect most mods will always be just a single version [range].
Quote from Arantor on July 4th, 2011, 10:02 AM
Board permissions confuse a lot of people and 2.0's move to using profiles for boards is even more confusing. I know the entire setup needs to change but I'm not yet sure which way to go for the best.
I'm not sure either, but I'm certain it involves impersonation or in other words "sudo."  Bugzilla, for example, does this and they only have like 7 permissions.  That said, its permissions also confuse me (because there are all sorts of overlaps, I feel like really it would be easier if there were more permissions or something...), but at least I can see what they do by impersonating someone.

And as much as I hate UAC the way it works in Windows, I like the concept of opting in to having lower privileges for a period of time.  It's something I probably would use, especially e.g. on a forum like Yourasoft, where I might not want to have moderation privileges or be able to see all boards (both were issues there, and we eventually used a shared admin account, which is a horrible idea from a security perspective.)
Quote from Arantor on July 4th, 2011, 10:02 AM
From my perspective, the calendar as it stands is not that useful, so having it in core is not necessarily the smartest move, but if it were to be more useful, there would be more reason for it to be present.
I would still take it out (if I ran a forum) and just drop a link in my menu to a Google Apps calendar (if I even needed a calendar.)  I would also remove PayPal / any payment stuff (in fact, that would be the very first thing I'd do) and if that HiveMail or whatever mod got integrated I'd remove it too.  I'd remove the moderation center, dumpdatabase, any friendly theme editing features (and especially the viewfile thing in the error log viewer), and definitely the "block me from logging in whenever a hacker wants to spam my account to lock me out" feature which has inevitably been added in order to compromise my security.  I would use none of these things, and they could only possibly reduce my security at worst, and insignificantly decrease my forum's performance at best.
Quote from Arantor on July 4th, 2011, 10:02 AM
I don't think there's any way to avoid that, though. Every time someone writes some code and releases it, it adds to the total substance of what's available - and every time that happens, there's one or more people out there who won't roll their own version of the same. From my POV, I see it as priming the pump for the most part, because I know others out there will think of ways to expand on what we come up with, and I know I won't be writing every possible permutation of mod either, so others who want it differently will invariably come up with their own spin on it.
Well, it's not necessarily always a bad thing.  I'm just more of a "wait and see" kind of guy for things I don't want.  I love building things I do.

I think a great example is WikiLinks.  I liked that mod, and I thought the feature rocked.  Ultimately, I didn't feel it was right for release, and there were a few complications with it... but it seemed like a perfect mod to me.

-[Unknown]
Title: Re: Unknown's thoughts on Wedge
Post by: Arantor on July 4th, 2011, 11:37 AM
Quote
I think they're fine an all "hookable" in some fashion, although whether hooks would necessarily be forethought for all these areas is uncertain.  Th only area I see a theme potentially wanting to touch is the IP one, and probably not.
Well, each page of key areas (like the profile) should have some kind of hook to it, then combine that with the template list and you're done. I don't think having a hook for each area of things like the profile, or even the admin panel, is that onerous, really.
Quote
Ah, good.  While I think no one uses that feature (at least they didn't used to), I think it's a good feature.  It came from YaBB SE and probably even YaBB, originally.
It is recommended periodically by the SMF support team, but honestly I suspect that's more because it's "find and repair errors" as if it's some magic tool, without understanding what it does.
Quote
Still don't agree that the core should have a working kitchen sink that churns out boiling hot and cold water
Interesting analogy, and one I can see the merits of, even if in this particular case I don't agree. To me, if you're going to have a kitchen sink, while all it *needs* is cold water, its power is greatly increased with hot water too. In this case, it's having a safety net of people removing posts without really removing them - prevents people abusing the system too much, IMO.
Quote
Well, edge cases are important.  Even if just knowing about them and documenting them.
*nods* I try to take such things into account.
Quote
In this case, I think I've seen before a "hook weight" where you can basically say "I want to be first"
I did think about that, but even then I can still see cases of two hooks requesting to go last, and I ultimately considered that the times it occurred were sufficiently rare in most cases that it could be dealt with by the mod's author where necessary.

Though if I do resurrect the stuff I was working on, it might not be a bad idea to have some kind of facility for this.
Quote
I don't see the point of picking a specific version to emulate when it seems as if the software can figure this out itself.
Well, you could do it that way, I guess, but right now it can't actually do it. All it can do is search through the package for any versions which match and if it doesn't find any, bail. But there are still some abuses of the system going on, like specifying 2.0 - 2.0.99 which worked even for release candidates...
Quote
Originally we set out to move to the DB and that was it.
I don't think the upgrader looks at it, though... been a while since I looked, and it was more a curiosity and something of a bug, but one I was never that interested to investigate.
Quote
And as much as I hate UAC the way it works in Windows, I like the concept of opting in to having lower privileges for a period of time.
Interesting. I always felt the opposite, that what is in SMF and Wedge with the secondary validation, that you're practically doing exactly what UAC does: a secondary confirmation that you do indeed want to go into the administrative areas.

I still wonder about my methodology from SimpleDesk, which turned it into role-based permissions which could be attached to groups - but still effectively separating permissions from groups directly for the most part. (Then, mix in role templates, and you get all kinds of interesting scenarios)

http://www.simpledesk.net/community/simpledesk_team_blog/the_new_permissions_system_simpledesk_1.1_709.0.html if you're curious. Admittedly, it is helpdesk-centric and it's more complex now than it was when I implemented it and discussed it there (namely, departments support, which is similar to tickets in boards but slightly more complex in other ways), but I'm sure there's something of consideration there. The implementation, though, I probably would do differently now.
Quote
I would still take it out (if I ran a forum) and just drop a link in my menu to a Google Apps calendar (if I even needed a calendar.)  I would also remove PayPal / any payment stuff (in fact, that would be the very first thing I'd do) and if that HiveMail or whatever mod got integrated I'd remove it too.  I'd remove the moderation center, dumpdatabase, any friendly theme editing features (and especially the viewfile thing in the error log viewer)
I understand where you're coming from, but OTOH, I have arguments that encourage me to keep some of them too:
* calendar, because I think it can be made more useful and worth keeping around as a consequence
* PayPal, because I take the view (much, as I think the team did at the time) that anything payment related, I'd rather have that in the core than a possibly unmaintained mod, for security purposes
* HiveMail... not sure what you mean? Certainly there aren't any mods named that on sm.org.
* Moderation center... I suspect that was implemented in response to how vB did things. It's not ideal and needs reworking, but removing it entirely, down to the concept of it, is not really where I think we want to go: managing a busy and active forum through just email-to-all-moderator notifications means that things do get forgotten and unresolved.
* DumpDatabase - agreed.
* Theme editing - I think we already got rid of them, and if we didn't, we're in favour of doing that.
* ViewFile thing... hmm. I can't see any huge reason to get rid of it, and I can see a smallish reason for keeping it: people *do* post its output when things are broken, because when you have file edits, it can show what's broken. Though for the most part I'd probably argue it doesn't help, but that doesn't mean it hurts to keep it either. (Curious, what about it don't you like?)
Quote
block me from logging in whenever a hacker wants to spam my account to lock me out
That has actually been removed even in SMF.


:edit: Oh, I missed this one:
Quote
I'd add code afterward that would do e.g. $actionArray['x'] = array('y', 'z');.  While "ruining" the style, this didn't ever break and my mods were fairly low maintenance.
Until you have half a dozen mods that all do the same thing, all attached to the same comment and none of which can be uninstalled unless you remember the order of installation because of the way find/replace is done in packman.
Title: Re: Unknown's thoughts on Wedge
Post by: snoopy-virtual on July 4th, 2011, 04:13 PM
Quote
ViewFile thing... hmm. I can't see any huge reason to get rid of it, and I can see a smallish reason for keeping it: people *do* post its output when things are broken, because when you have file edits, it can show what's broken. Though for the most part I'd probably argue it doesn't help, but that doesn't mean it hurts to keep it either.
In all the time I have been giving support, I have seen some people in cheap servers with no FTP access nor a good control panel, so the only way they have, if they ever need to edit a file, is using this feature.

If file edits are going to be ever needed I would even suggest you could extend that feature to all the files (not only the Theme files) for that people without FTP.
Title: Re: Unknown's thoughts on Wedge
Post by: [Unknown] on July 4th, 2011, 10:09 PM
UAC: Well, no.  UAC is very different from, say, sudo or etc.

UAC hits you with a heavy hammer.  Unlike sudo and most other systems, it asks you *every time*, resulting in user training.  It's also for anything that isn't something a standard user can do: for example, UAC would require a password prior to moderation.

SMF does require the password (mostly as a last-effort against CSRF or session fixation), but only for logical administrative functions - editing profiles, the admin center, etc.  At least it used to.

But, I don't need to type a password or confirm a prompt to go into an admin-only board, or post a reply to a locked topic, or etc.  That's what UAC does, and I don't agree with it or like it.  That said, being able to opt into that situation seems interesting.

Permissions:

I think I've talked about this before, and how roles make more sense.  Looking briefly at that super long post, it seems like you're doing the right thing: create "groups" of permissions, aka roles, and assign users (or groups) to these roles.

It's really how I meant for groups to be used, but ultimately, it's confusing.  When you start with "Guest", "Member", and "Administrator" it is not natural to think of creating an "Attachment Poster" or "Poll Starter" group.  It's the same context problem I was talking about before.

If mods created default roles on installation, and SMF/Wedge came with a healthy set, this could be a good thing.  I know I posted at length about this on SMF somewhere, and I can't remember some of the details of the system I tried to think out.  But in general it's a lot clearer than "additional groups."

It looks like that's what you have.  Also the own/any/all thing, dropdowns make sense.  I wasn't sure about the UI ever, and was initially trying to go with checkboxes with deny.  I wanted to expose the option to allow people to, e.g., lock any topics but their own (which can be done with deny) because there were interesting use cases people had asked for that required this (even though it was a <1% type of thing.)  Probably this was a mistake, because deny is something that users just don't generally understand well.

I think instead of board permissions, you might have roles be "global" always, and when you assign roles to a group or user, make the board-specific association there.  For example, when editing "Global Moderator" (a group), I might set them to be in "Standard Users" for all boards, and "Attachment Posters" for only boards (or departments or galleries) x, y, and z.  And I might put them in some other role for all boards except a, b, and c.

In fact, denying them a role may make more sense than having permission-level denies, and may work for users in their heads.  I'd have to talk to a few users to figure that one out.

The interface could offer roles for board-specifity based on them having board permissions.   Same with gallery or departments.

Then once you've "built" the group, and tested it by impersonating the group, it's much easier to assign and understand what will happen, because that group is all on one page.

Ultimately, in the same token as file editing, I think that "additional" groups should be something most people almost never use, if possible.  Having seen users try to use them, they are only confusing to them, *especially* with the whole Regular Members/Ungrouped Members conundrum, which needs to be gone yesterday.
Quote
* PayPal, because I take the view (much, as I think the team did at the time) that anything payment related, I'd rather have that in the core than a possibly unmaintained mod, for security purposes
I'm not saying whether I'd take them out of the distribution (although, this I would, but probably for legal/liability related reasons), but that I would remove them from my own install, where I'd never use them - as a general clarification.

I understand and agree, to a point, with your argument that it's better if it's more strongly maintained, since it's an important feature.  That said, I've never been to or used a forum that requires payment for anything or in any way related to the forum, aside from simplemachines.org.  I've used forums related to paid products (such as hardware or software or physical goods or even services), but none of these seem to "fit" with the payment features in SMF as I understand them.

So to me, in this particular case it just seems like additional risk for, what, adult content forums?  Those were like specifically what I didn't want to cater to.  If I could add a feature that would make those sites less likely to use my software, I'd consider that a big plus under the "reasons to add this feature" column.

I'm also not sure it's a benefit to end users, since I would assume it can only encourage making them pay for access in situations where that may not make sense.  But ultimately, that's a problem for the free market, so not a big deal.
Quote
* HiveMail... not sure what you mean? Certainly there aren't any mods named that on sm.org.
HiveMail was a mod to integrate some web based mail solution into SMF.  I may be remembering its name wrong.  It was actually one of the first paid mods.  I thought it made it so you could give each and every user of your forum an email address, automatically IIRC.  Or something like that.  I never looked hard at it, and I think just helped the author some?  Memory is very fuzzy.

ViewFile: it makes my security hairs stand up on the back of my neck.
Quote from snoopy-virtual on July 4th, 2011, 04:13 PM
In all the time I have been giving support, I have seen some people in cheap servers with no FTP access nor a good control panel, so the only way they have, if they ever need to edit a file, is using this feature.

If file edits are going to be ever needed I would even suggest you could extend that feature to all the files (not only the Theme files) for that people without FTP.
I realize there's a "thriving" community of forum-only hosting.  That said, I personally feel that if the host doesn't want to give them any access to the files, we shouldn't either.  Especially if the host is doing something like BoardNation was, with a shared sourcedir setup.  Then it could even be dangerous.

-[Unknown]
Title: Re: Unknown's thoughts on Wedge
Post by: snoopy-virtual on July 4th, 2011, 11:36 PM
I didn't know there was hostings sharing the same sourcedir between a few forums. It would be very dangerous indeed if they could edit the files there.

Well ... My first advise when somebody comes with that problem has always been: "Change your hosting", so I suppose I will stick with that one.

One thing is sure, I would never use one of those hostings.
Title: Re: Unknown's thoughts on Wedge
Post by: live627 on July 5th, 2011, 12:24 AM
Quote
UAC hits you with a heavy hammer.  Unlike sudo and most other systems, it asks you *every time*, resulting in user training.  It's also for anything that isn't something a standard user can do: for example, UAC would require a password prior to moderation.
UAC was notorious for that in Vista. It has been tweaked in 7 where it doesn't pop up so often but I was always an administrator so for standard users where it requires a password, it;s probably still bad.
Title: Re: Unknown's thoughts on Wedge
Post by: Clara Listensprechen on July 12th, 2011, 03:20 AM
Quote from Eros on June 28th, 2011, 04:27 AM
I figured I'd toss my two cents in, as someone who more or less, has always intended to go around SMF (except for bridging authentication) as much as possible. That, and I'm not a web developer, so it is easier for me to work that way and fix my own mistakes without affecting an adequate solution. I also have a tendency to react without thinking things through simply because of some of the things I've seen in my limited experience .

File edits are a pain in the ass to maintain between versions and so are hooks. I don't think either is going to change developer behavior sufficiently to be worth picking one or the other solely for that reason.

If you provide Hooks, you need to also provide File Edits to avoid Unknown's concern of people causing trouble that way.

If the real, and only concern, is the size and quality of mods...you are probably better off coming up with positive incentives to create certain types, and a certain quality, of mods rather than relying on the method of modifying Wedge to do it for you. I've got no good idea how to go about that simply because I've never tried to foster a developer community around a project outside of a situation where everyone is being paid to care about said project.
I'm glad you did toss your tuppence in, actually, as I'm no web developer either, but one of those people who has gotten into repeated trouble with file edits (but after days of cussin' & fussin', it eventually all worked out and stuff was exactly the way I wanted it, and it's why I've stuck with SMF stuff, and why I'm interested in testing out Wedge when it's available).

As a person who knows only enough code language to get my face slapped, please pardon this next question...what the heck is a hook, and if I fiddle with hooks, would that make me a hooker? (okay, so that second half wasn't serious.  Insert LAUGH here).

Seriously don't know what "hook" refers to and I'm dying of curiosity.
Title: Re: Unknown's thoughts on Wedge
Post by: live627 on July 12th, 2011, 04:52 AM
http://wiki.simplemachines.org/smf/Integration_hooks
Title: Re: Unknown's thoughts on Wedge
Post by: Clara Listensprechen on July 12th, 2011, 05:27 AM
Bookmarked!  Thank you very much.
Title: Re: Unknown's thoughts on Wedge
Post by: Nao on July 12th, 2011, 07:31 AM
Just keep in mind that the Wedge version has a wider use/reach. :)
Title: Re: Unknown's thoughts on Wedge
Post by: Clara Listensprechen on July 12th, 2011, 04:46 PM
So I gather, from what I've read on this board. Can't wait to try it out.
Title: Re: Unknown's thoughts on Wedge
Post by: Norodo on July 12th, 2011, 04:58 PM
A problem for SMF is that it actually has quite a few hooks, but people don't really use them as much as they should, from what I can see.
Title: Re: Unknown's thoughts on Wedge
Post by: Clara Listensprechen on July 12th, 2011, 05:20 PM
When I holler for help on SMF Community or when I discuss a situation with an SMF authority (that is, who is more familiar with SMF code than I am as well as a mod designer), the advice I get is to look for such-and-such code line and to change that line to such-and-such. Hearing about hooks here is the first time I've heard of hooks--and for all the times I've caused my board to crash just because of unintended consequences involved with changing a line of code, I know I'm going to look into hooks as an alternative as that does seem to be the better idea. Could have used that information when forcing the Shoutbox to make a sound when a Shout was made, too, dang it; could have put one in to use/used one, perhaps.  Oh, the agony of those times...!

Yeah, this is important information from where I'm sitting.

==============================

Oh---I might as well mention that one of the reasons that I've not upgraded to 2.0 Gold on Hypercrites Flipside is because a lot of mods I'm fond of work with the RC version I am using. A dream Wedge would be that stuff like Arcade and Gallery etc won't have to be rewritten to accommodate some core change each time there's a revision. That's been a huge headache for me with SMF and the main reason I won't upgrade a well-used board.
Title: Re: Unknown's thoughts on Wedge
Post by: Arantor on July 12th, 2011, 05:23 PM
SMF has had hooks for years, but they were massively crippled prior to SMF 2.0 RC4, as in each hook could literally only do one thing. That was fixed in 2.0 RC4 so hooks could do plenty of things, but there are other limitations that I'm not going to get into at this time.

Part of the problem is that not a lot of people are trying to use the hooks, because a file edit is often easier, but more of the problem is that there aren't enough hooks, meaning that file edits are the only solution, rather than a necessary evil-of-sorts.

Take SimpleDesk 2.0, I spent ages trying to figure out if I could hookify lots of it but in the end I realised that unless I went through an awful lot of pain (and some of the pain I did go through anyway because it wasn't *too* much), you can't do it anyway.

For example, let's say I want to add something to the end of the unread/unreadreplies page, as SD does. Since there's not a hook, the only viable way I could do it was to put a new function in that wraps around the existing unread function, and drops a new template layer in with my new content - with the unread stuff none the wiser. But that's very convoluted and if I didn't already have some new-action processing going on anyway, I wouldn't take that level of effort into it, it's just too much hassle.

If something has a hook that does what you need, great. Trouble is there's a real shortage of hooks - all the login/account creation/activation stuff has hooks, as does new topic, plus some for *really* common areas like permissions, bbc and menus, but other than that you're pretty much on your own - which means file edits are the only alternative.
Title: Re: Unknown's thoughts on Wedge
Post by: Nao on July 12th, 2011, 05:31 PM
Quote from Clara Listensprechen on July 12th, 2011, 05:20 PM
A dream Wedge would be that stuff like Arcade and Gallery etc won't have to be rewritten to accommodate some core change each time there's a revision.
When it comes to the gallery, I see you're using SMF, so you'll definitely to have to upgrade to Aeva Media 1.4 if you want to then be able to import it into your Wedge forum (although TE might wanna support SMG as well, but frankly I wouldn't do it if I were him. There's already a perfectly well written upgrade script in AeMe.)
Plus, I believe there are security issues in SMG that were fixed in AeMe ;)
As for Arcade, it's a big mod AFAIK and I doubt it'll be ported over. At least not easily. Perhaps I could give it a try, but it would have to be BSD'ed first.
Title: Re: Unknown's thoughts on Wedge
Post by: Clara Listensprechen on July 12th, 2011, 05:36 PM
I see. Well, with the Shoutbox situation I was envisioning editing a file to put hook capability in at the right place and have the thing do what I wanted it to separately, as opposed to coding the function directly into the Shoutbox file, which is what we ended up doing.
Posted: July 12th, 2011, 05:31 PM
Quote from Nao/Gilles on July 12th, 2011, 05:31 PM
Quote from Clara Listensprechen on July 12th, 2011, 05:20 PM
A dream Wedge would be that stuff like Arcade and Gallery etc won't have to be rewritten to accommodate some core change each time there's a revision.
When it comes to the gallery, I see you're using SMF, so you'll definitely to have to upgrade to Aeva Media 1.4 if you want to then be able to import it into your Wedge forum (although TE might wanna support SMG as well, but frankly I wouldn't do it if I were him. There's already a perfectly well written upgrade script in AeMe.)
Plus, I believe there are security issues in SMG that were fixed in AeMe ;)
As for Arcade, it's a big mod AFAIK and I doubt it'll be ported over. At least not easily. Perhaps I could give it a try, but it would have to be BSD'ed first.
When I test-drive Wedge, it's going to be a clean install on a subdomain (eg hxxp:www.hypercrites.org/Test) and I intend to do fresh installs of Gallery and Arcade rather than import. What I mean, though, is that in future versions of Wedge, the Gallery and Arcade (and whatever else I might add) would be able to operate without upgrade or code edits as virtual stand-alones regardless of what I might upgrade the main board to.

This dream might not be realistic from where you're sitting, but it certainly be ideal.
Title: Re: Unknown's thoughts on Wedge
Post by: Arantor on July 12th, 2011, 05:38 PM
Yeah, you could do that. The only problem is, the hook won't do anything.

Remember I said about SMF's limitations? One of the more interesting limitations is that the hooks can only run functions that currently exist. Which means if you have an external file with your hook function in it, you can't use it - unless you load it first. Except there's only three places (IIRC) that a hook will actually be able to load a file for you: once every single page, once inside the admin panel and once inside the profile area.

For the hassle you might as well just edit in the hook point and have it call a function in your existing file - the result is basically the same, and without the overhead of having to ensure it's in the DB.
Quote
I intend to do fresh installs of Gallery and Arcade rather than import.
Good luck trying to install Gallery. Specifically, if it's SMF Gallery Lite/Pro, you are never (EVER) going to see that on Wedge, I guarantee it. (Not only because he won't port it, because of our past dealing with him, I don't really see him being allowed on here much.)

As for AeMe, that's already integrated and going to be *further* integrated.

The other thing is, it's possible we might change the hook functionality in the core - which would necessitate an upgrade of add-ons anyway.
Title: Re: Unknown's thoughts on Wedge
Post by: Clara Listensprechen on July 12th, 2011, 06:41 PM
Interesting. As it happens, I'm currently using Aeva...and you're right, as I hadn't given the DB a thought and I should have.  Something else I gotta learn, perhaps the hard way like I've been learning everything else about SMF ;) Not having to mess with the DB concerns would be handy indeed.

Thank you very much for this valuable information.