Wedge

The textarea is not part of the template, it calls the richtext editor component elsewhere, so the actual textarea is only supplied when template_control_richedit() is called.

For setting the body, look for control_create_richedit(). There should even be an example of grabbing the body of a PM and injecting it when quoting a message ($_GET['quote'] will be checked for, and $_GET['pmsg'] will be set in that case)

For setting the subject, that'll be a regular <input> not a textarea control.

That would require me buying a vB licence and learning to code for vB, neither of which is going to happen any time soon. There is more chance of my learning to code for xenForo than that - but I have Wedge instead ;)I want to be surprised by that, but I'm not. Given how poor some of the paid mods for SMF are, it doesn't surprise me to see that people are trying to make a quick buck with some trash on vB.To a point that's unavoidable. If you're modifying something inside a template with a mod, it's almost certainly going to have to modify the template to make it work. But that's only for very specific changes, for a lot of things the modular approach that Wedge has will remove that need.

Yup, never mind that people are volunteers doing stuff in their free time, and that folks have sunk thousands of hours of their free time into making this, I WANT MY FREE SHIT, DAMMIT. :niark: It actually really pisses me off. I don't mind particularly that I made dozens of mods for SMF, I don't even mind that I didn't get much in the way of thanks, but I did mind the amount of people who seemed to be under the impression that they had any right to do anything other than ask me if I'd add things or change things, as opposed to expect, demand or in one hilarious case, threaten me with a DDOS in order to make him what he wanted.

It doesn't help that while there are three (AFAIK) paid theme sites for SMF, each with a decent amount of reputation that they've legitimately earned, there are three paid mod sites, of which only one could justifiably claim to have good standing, the other two are clearly out for whatever they can get, including buying up other mods and taking over other mods just so they can promote the crap out of their own paid stuff.[1]

I will say, though, I had an interesting discussion with vbgamer once on the subject, in particular reference to the ad management mod after he'd bought it. The mod's free (branding notwithstanding) and because it wasn't using template layers and so on, it did a number of core template edits. Needless to say: support nightmare. So he started offering a paid service to install it, $15 a time.

I don't have a problem with that. The thing is free, and if you aren't using the default theme, you can install it yourself with fairly minimal effort. But if you want someone to do it for you, it's only fair that you should pay them the time to do it.[2]

And yet, he was annoyed - and I agreed with him about it - at the number of people who didn't want to pay the $15 for him to do, but also didn't want to do it themselves.


One other little anecdote. I once talked about doing the vBookie mod for SMF. It's a simple enough project, really, but it would have required template edits to do properly, and would be big even if it was pretty simple. So I talked about the fact that I didn't want to do it for free, and that I thought $25 was a reasonable fee for it plus a year's support, or an extra $15 on top for me doing the installation for you. Cue a surprising amount of nasty feedback - I was genuinely surprised at the volume and ferocity of some of the messages, even though I thought it was quite reasonable.

So, I then said, fine, I'll look at doing it for free, but for 2.0 only to make *my* life easier, and look at maybe charging for support because of the complexity of it. Even that triggered a surprising amount of crap, though not nearly as much as before. People just do not want to pay for stuff, generally speaking, for a free platform.[3]

What it comes down to is investment in the platform. We have a rather irrational take on sunk costs, that we'll often spend over the odds not to have wasted the initial sunk costs, such that when you spend upwards of $200 to get into the platform in the first place, you're prepared to spend a bit more on add-ons for it, even if you could actually achieve everything you wanted with another platform.[4]

1.	Exactly who I'm referring to will be an exercise for the reader.
2.	For most themes, $10 would be enough in my book, but that's another story. The principle of paying someone to do it is entirely fair game, after which you're just haggling over the details.
3.	I wouldn't mind so much if those people contributed back in other ways, e.g. support, but very often not even that happens.
4.	It is much like the iOS vs Android situation. People who buy into the Apple ecosystem are invariably prepared to pay for apps, not just because they're presumably able to do so, but because they have also the sunk costs mindset behind them.

Bridging Wedge to WordPress will be strongly discouraged for a lot of reasons, not least the fact that Wedge has blog support built in, and that SSI is simply not designed for that kind of integration.

In any case, calendar support is going to be removed from SSI and turned into part of a plugin, though SSI should still be able to make that usable... (that part's a WIP)

When I originally did it, I just hit up every place where call_hook was used, without being specific in terms of variables.

The plugin manager is a very very big thing for me, I want to get it right.

Now, as I've mentioned before, the idea is that daily it's going to call into the different plugin servers listed and see if there are any updates to any of the plugins you have. (Yes, you can turn this off! But it makes sense to make it on by default, as it were.)

The other thing you'll be able to do is provide a username/password for private sites so that you'll be able to be notified automatically of updates - even on private mod sites.

Here's a demo of the screen as it stands right now - you'll notice the old 'download from a URL' option is gone, and that there's a revised upload and download area (with adding a repo / package server being on a new page)

On this particular case, I've set it to fake being 'error' (so that if it couldn't call a given site, it flags it as in error and won't call on it again until you reset it, to avoid repeatedly trying to hammer broken links etc), and I've manually put in a user name into the system so it displays the fact that there's a user account attached to that server.

(I also happen to think it's more consistently styled compared to the rest of the admin panel, but that's just my biased view :P)

Right now it's a hook but yeah, that would have to change.

The easiest route I would imagine for it would be to have an array holding the possible paths that will be examined by the autoloader, and have it allow that to be extended.

I am trying to avoid cluttering up the plugin subcaches in the modSettings area so I'm not entirely sure how best to manage it but it is likely a centralised listing providing class name -> file path would be best, because it's cheap to search such a listing and load it directly in the autoloader rather than searching.

SSI is a big beast of a file, and it ends up loading a couple of thousand lines of code, of which a lot of users won't even be using. If, for example, you just do authentication with it, you won't use most of the code there.

Then you have the functions themselves. My personal favourite is ssi_boardNews, which is:

There are some issues with this. For example if you want to get the information back you can't just use (the rather logical):

It just doesn't work like that.

Then you have the facilities I built into http://custom.simplemachines.org/mods/index.php?mod=2280 for multiple boards and much more stuff. Which, you'll notice, doesn't one massive function call, you set all the options you want first.

So, I thought... how about we do something similar, but cleaner and able to be much more configurable?


Here's what I'm proposing.

Instead of ssi_boardNews(1); to get the news from board 1, I'm thinking about:


It looks worse, but hear me out. There are a bunch of things that can be achieved with this.

Firstly, we can remove all the SSI functions out of the file and put them somewhere else, so that you only load what you need, and we achieve this with a thing called an autoloader. (Specifically, an SPL one, but don't worry about that.)

So you just request SSI_boardNews() as a class like above, it goes and makes sure the class is available and boom, you can output the board news with it.

But having it set up like that means it's trivial to add different options at will - instead of having a massive function call to set the number of items, the start/length/whatever, you can set all those with separate calls, e.g. to get items 11 to 20 (page 2), the first 500 characters, you would do:


And there's no set order, no requirement to list all parameters, just the ones you want to change compared to the default. (I could even put the board number into the SSI_boardNews call itself for keeping it small's sake)


Thoughts?


:edit: Interesting side benefit, it would allow you to be able to load individual SSI components as needed without having to load the entire file.