Wedge

Skeletons are a truly OOP class. That's the only one I ever wrote to be OOP, but guess what, it's also the only one that could benefit from being OOP.
Do you have any other idea what could really benefit from OOP..?!But SMF is already MVC to begin with...I don't know much about these, so I'll pass.We were supposed to release much earlier, which is why we always postponed giving more writing rights to anyone in the team. Really, we simply refused write access to *anyone*, not just you... And now that Pete is gone, I'm working on that. Beginning with the conversion to Git, and support for pull requests (since yesterday.) So, if you want access, there's a topic for that... ;)
I'm afraid I don't remember you ever asking for commit access to the main repo, though...! I don't remember you providing any patches either. Only Shitiz and John did. You wrote the importer, and then you got feverish when one day I confirmed that we were going to go with the original SMF license and were considering a paid version, and you didn't want anything to do with that, and you left. Then you saw that we didn't implement that, and you came back later, and then one day you left again, for no apparent reason.

It just stuck with me that you were more interested in helping Elk than Wedge, is all.I don't know, how different are they exactly...?
It's not like they're incompatible, either...
Except for Wedge blatantly breaking mod compatibility, of course! :P
(And Pete never ever documenting any of his codebase changes... :whistle:)

Yeah, he doesn't need that to blame himself... ::)Okay, I got it: from the list of links I gave, you have to click "691" or whatever in the header, and then click on the commit link that's in the first comment, or something. This adds an extra 2 clicks, but then you get the original commit[1].

So, basically, Github is the culprit here for not being very helpful to people who might read these pages without knowing a thing about Git or Github or whatever. Regarding the argument about the use of 'wesql' in the codebase, this obviously makes it moot, but that still doesn't change the fact that (and even Arantor recognizes it himself) all of his work on SMF 2.1 is to bring Wedge features to it, which *obviously* is reason enough for me to be pissed off by his actions.

Remember, two months ago, he argued that he was leaving the forum software community to focus on making use of the Unity engine and create video games with Asgard. Something I could perfectly understand; in fact, the only times I considered leaving Wedge, was because I figured I needed to do something to make a living. Well, in the end, not only did Pete stay in this little world, but worse, he chose to go to the only place we expected each other never to deal with. The very place that had us create Wedge in the first place. And not only that, but now he's contributing his Wedge code to them (thus removing value from the project he poured his heart into for three years). He's shooting himself in the foot, wasting his time, and hurting me. Had I left Wedge before him, I'd never have done that kind of deal. I have a fucking conscience. All code I wrote for the team, is for use within the team only, at least until the day Wedge uses an actual open source license, at which point, everyone have fun. I don't have any right to reuse it for the competitor we left in the first place because of the way they treated us[2].

All I'm saying is that I feel Pete disrespected me, by systematically doing the opposite of what he assured me he would do. So, the next things I'm expecting, are for (1) his Wedge repos to disappear without warning (reason enough to move them), and (2) for my code to find itself in SMF. "By mistake", of course. But there will always be a revision log to make sure not a single line of my Wedge code finds itself in SMF. So, now what I'm *hoping* for (rather than expecting), is for Pete to take a local copy of Wedge, and only copy-paste code from HIS revisions.

That's all there is to say.

1.	I thought that branches in Git allowed for pull requests to essentially be a merge, which isn't destructive like a rebase, and kept all of the original commits. Looks like it creates an extra reference to the same commit, with a different hash. Oh, I have to read more about that...
2.	Again: I have nothing against the current SMF dev team. I'm referring to the remainders of the 2010 SMF 'management'.

<sigh>
From what I saw on the Github site, because Arantor 'merged' the commit, and he had his name in bold (while the live627:ssi branch is in small-size Courier New characters), it wasn't hard to imagine that he committed it.

Let's see the path that I followed...

https://github.com/SimpleMachines/
Click SMF 2.1. Brings us to...

https://github.com/SimpleMachines/SMF2.1
Search (ctrl+f) for 'wedge' in the page. The last commit on SSI.php has it, so it's plain in your face (and the reason why I mentioned this thing at all, because I'm afraid I don't spend a lot of time on either Elk and SMF codebases, ahem.)
Click the link. Brings us to...

https://github.com/SimpleMachines/SMF2.1/commit/aec98628cbc78d30a38f2dcf68dfc747740a899f
"Arantor authored 14 days ago"
Click on "1 parent: (hash)", top right of the page. Brings us to...

https://github.com/SimpleMachines/SMF2.1/commit/444bdeac2797b058b2eac26cf756d7c57f2053d9
In the very same place, it says "Arantor authored 14 days ago".

So, believe what you think, but to me, it seemed obvious that Arantor made both commits... It's what Github insists on saying after exactly THREE clicks from the SimpleMachines homepage.

Is Github that fucked up, or is it Pete who did the wrong move and found himself crediting himself for someone else's work?

Nothing more than a vanity hack... It allows the skinner to fine-tune tabs (spaces) per-block in the HTML source code. I wrote it for use within skins that would want to move around the sidebar, like Warm did, but it's lost some of its value by now. Plus, I'm the only one around who cares about HTML formatting, so, whatever... Not worth discussing, really, it's only for the anally retentive like me ;)Ah, PHP Nuke, and its 'successor' PostNuke... I actually tried to build a website using those, back in the day...! (I ended up using SPIP, which had the better codebase; the website is still live, surprisingly.)

I'm responsible for *most* of the ob_sessrewrite additions. Next thing you know, he'll say he always hated Wess, never thought skins were a good idea, and thought skeletons to be stupid. When I only said what I'd always said: that I didn't like the admin homepage. And that's the only admin area page I ever shared my concerns about. But it looks like Pete still has issues with his self-confidence, and he has to prove to everyone that he knows best. Oh, well... Hopefully, he'll grow past that.

This is what it does, in addition to what SMF already did (the non-trivial blocks of code are indicated by a star):

- Turns all http://wedge.org/ tags into the actual board URL. Which is a feature Pete loved.
- A meta description hack (by Pete)
- Hooks
- Showing header CSS, the elegant way.
* Delayed events -- making for much faster page loads, even when using jQuery. Could be disabled, but that would imply loading jQuery systematically from the header, which on the first page load, may be quite visible. I'm not against putting this into a setting, but nobody ever even suggested it. (Also, Pete loved it.)
* Soft-merging of posts. Wanted to put that into a setting, but it was such a popular feature (including with Pete), I decided against it.
* Macro replacements. Very powerful. Enabled through skins.
* Skin replacements. Even more powerful, but use with care. Enabled through skins.
* Membergroup colors. Written by me originally, but Pete bloated it up to use classes and caching. I was in favor of this, but Pete, don't tell me I'm always the cause for bloat, all right?
- Hiding profile links for users who can't view them.
- Topic prefixes
* Pretty URLs (probably the only feature in this list that Pete didn't like.)
- Indenazi hack. Only executed if used in a skin.
- HTML minification; only executed if a secret setting is set...
- Link shortening (this is different from pretty URLs; it doesn't change links, only makes the page easier to compress.)

Most of these features could (and I think it was brought up at some point) be moved to their own functions, as long as we're providing a link to $buffer of course, but it's really just a matter of ethics.
What happens here, is that these features are *best* placed in ob_sessrewrite, because it saves time, and makes overall coding easier for plugin authors (e.g. they don't have to care about membergroup colors themselves, as Wedge does it for them after they output their HTML.)

Now, if we ignore his comment about page processing, I'm afraid I can't take seriously the mention that the 'code is better in SMF'. If anything...

everywhere, versus

I'm only very sad to see Pete actually forgot the three years he spent on improving the SMF codebase with me. He's back about two years before, and suddenly finds himself in a position where he can't break existing mods and has to cope with all the crap in SMF (same crap that is mostly gone in both Wedge and ElkArte), so he could hardly make a point about that.

The SMF codebase was fantastic and very modern in 2003. We're in 2013. Either SMF keeps mod compatibility, or it gets a better codebase. But it can't have BOTH, thus making Pete's point completely absurd.

Okay, I promised myself I wouldn't reply his post, so I'm going to stop there, because technically I'm replying to a sentence of it through a quote... -_-

I've always shared security issues I found. They just didn't care.

I don't know where their security advisories are posted, though...

I don't think more than a handful of GH users are using it to its full extent.
Here's what one learns over time: Git is needlessly complicated, but it still allows one to do things like SVN[1]. It just adds new features to it. Useless features, for the most part. Some of SVN's 'easy' features are also replaced with more complicated features, but that's where Google is your friend, I guess. When I need to import a SVN repo, I just do svnadmin load on my command line. When I need to do a Git repo, I'll copy & paste a long and complicated command I found on Google. As long as it gets done, eh..?The Wedge codebase will be out soon. But it'll first go through a short 'private' phase on Bitbucket, and then I'll move it to Github, when it's okay to do it.
Fact is, I don't really believe anyone will offer any pull requests for Wedge. Really, anyone who has read access to the Wedge SVN (or a zip of the late 2012 alpha) could have offered diff patches, it's easy to generate, but nobody did. (Well, John did a couple, which got integrated, but really he's the only one. Also, Dragooon wrote the initial notification system but it was as a plugin, not a patch.)
So, I really don't see any reason why others would provide anything, as desirable as it might be to me.Well, it's pretty good... But also complicates things if you're used to the SVN admin area, I guess...
It was Pete's thing. His area of expertise. I'm only getting started resuming work on it, but all in all, I know I'll eventually overhaul the most 'obvious' change he made to it, i.e. the homepage. I've never liked it.What do you do at SMF?Well, you do whatever you want, I'm not concerned with what people do with Wedge, as long as they follow the rules with it! ;) (i.e. no redistribution, and no copyright removal.)

1.	In fact, even GH's Windows application only shows the most basic things you can do with it; it's even simpler than TortoiseSVN in concept, so that goes to show, you don't HAVE to know everything about it... Thankfully.