Wedge

Scary for you - as long as I can add events inline and add deferred JS with add_js(), I'm happy.

I'm not really fussed where it is, provided that it works and doesn't break anything.

I don't know. All I know is that it's a regular link with an event attached to return ask('string') in it, the ask() fires, the return seems to be true but the link never fires after.

Should be reproducible on mobile too.

OK this one is officially weird. The delete link has an event attached to it which calls up ask() (our replacement of confirm()) but when it returns true, it's not calling the default behaviour on the link so nothing happens.

Yeah, that's been a problem for a long time. The main reason I haven't fixed it is because I'm not sure what the future of the theme area is.

The main issue is that the Current Theme is only really needed when you have multiple physical themes. Now, it's been the focus to have only a single physical theme and everything else to be done with CSS.

This raises the question: is it something we're going to push forward with in the future or not? For the core, I think this is going to come down to the eventual fate of the wireless setup. Right now, we have the wireless skin, which essentially drops certain layout items from across the site. It's an improvement on the default for wireless, but not by a lot. I'm increasingly feeling like I'd rather have a full mobile theme that has its own templates (a la Dragooon's SMF4Mobile), which means bandwidth can really be trimmed for mobile users[1] and that would be set up as a physical theme.

If it is a physical theme, we ensure that everything works - because right now, I really don't know how well any of it works, mostly because the skins system essentially has removed most of the need to care about it. On the other side, if we were to have a physical theme for mobile use, it could easily inherit skins for changing the colours and smaller layout items even on mobile, which seems pretty ideal to me.

1.	Since you only display what you need, rather than outputting everything and just hiding what you don't want. Helps the server as well as the client.

OK, so I've looked properly at the patch now, and I'm not entirely convinced it actually would work properly in SMF, let alone Wedge.

The return value of a called hook, particularly one where multiple functions might be hooked, is not what you think is. I might expect to see an array returned, sure...


In every case of calling a hook, it's done through building up an array where the return value delineates what hooked function returned what by referencing the name of the function that was called.[1] Aside from keeping things separated from accidental collision, it does mean you can't rely on $hook_errors being empty, because it should return an array of functions that have been called, even if those individual items are empty.

1.	Yup, it's not really any different in Wedge, the exact syntax is a shade different in our call_hook vs SMF's call_integration_function, but the principle is the same, having a variable accepting the result of call_user_func_array() and putting it into an array.

That isn't what I said. I said that had compatibility code in there from back in the PHP 4 days. The fact it supports older versions of PHP isn't inherently a bad thing, just as it's not a bad idea that software works on Windows XP when 7 and 8 are the current versions.It's the case. Trust me, if there were issues with SMF security, it would have been fixed in Wedge by now and very likely someone would have told them about it.Except that was the complete opposite of what I meant, and in fact of what I said. The problem isn't developer ego. It's everyone else who believes that their say is as important as the developers' say except they're not the ones doing the work.


As far as mobile posting on SMF, you could do a lot worse than smf-media.com's offering.

As far as blogs go, notice that it's not exactly prominent here and amounts to nothing more than a custom theme, and can't be made anything like what you're after without a serious rewrite, so much so that I've thought about dropping core blog support because it's too limited for most uses.And are they full width or fixed width?

Let me put it this way, I have a 17" laptop, with 1920x1200 resolution, and most forums being that wide (at, say, 95% width) just become hard to read. So many forums I know actually have a fixed width to prevent that being an issue anyway. But even though I have a large resolution, I invariably run my browser window at around 1000px wide because that's how the web seems to work best, not to mention the fact that it keeps the reading width about right.Because you're dealing with a very specific subset of the forum population. I however have had the interesting experience of providing support on sm.org, which doesn't have the sidebar out of the box and between there and here, I know which is more popular. You might not have had a complaint but I guarantee that if we make it an option, it's going to provide a plentiful source of support issues for us to deal with.And therein lies the other difference: Drupal is incredibly modularised. Ordinarily I wouldn't complain about that, but what that means is each module does its own work in terms of databases, as opposed to a flatter structure that gets all the data it needs for the current page or thereabouts. The result is something much more efficient for its own use (I've seen Drupal installations demanding quite literally hundreds of queries from the database to render a single page) but less directly configurable. But in any case, Drupal should not be a benchmark to measure against, except to measure how much faster you are. The ideals of pluggability are wonderful but the practicalities just don't stack up.I thought we'd already explained it did this before? Anyway, not without a code change and not a nice one. See if Uncle Nao is prepared to expend more bytes per page, every page.

The words do not come across as a request. Flat out insults do not usually come as part of nice requests.Then why move off SMF?SMF 2.0 went to a stable release a while ago, the updates since then have been security updates only. That's a sign of quality, not poor development, that it has only needed 3 patches of any kind since 'stable' release.

So I will say it again. Why are you upgrading? Are you doing it to get features you don't currently have, or because you perceive there to be a problem with the platform (that doesn't really exist)?I'm reasonably comfortable with the speed of our development. Getting snippy about that isn't winning you any fans.Because we learned the hard way what happens when you have too many people chiming in with their say. It's largely what's killing SMF, though not nearly the only thing.Where have we ever said it is anything else? We're not charging you for anything. We're not demanding anything from you. We're doing what we've always done, what we've always said we're doing, which is building it for us, and being nice enough to check with people that they're happy to use what we're doing in the process.There's a lot more to it than that. Firstly, as explained, there are logistical and practical reasons for having the sidebar - preventing the content taking full width modest-and-up screens is one of them.

Secondly, more importantly, let me take that concept for a moment: hiding the sidebar. Yes, you can hide the sidebar. Off the top of my head, I can think of two ways of doing it. Neither of them offer a nice cosy admin panel option for it, but it's doable - and it will have a lot of side consequences to doing it.

You're a programmer, you should understand better than most that these things rarely live in a vacuum, and that one thing often has a great many consequences.

But here's the other thing: many more people ask about putting a sidebar onto a forum, than ask about taking one off. You're the first person in 2.5 years to complain about the fact we have a sidebar. I'd argue we're doing a better job of catering to what people want than complying with every little whim that people ask us about.

But yes, just for you, I'm sure I could hack up a plugin that hides the sidebar, because I love hearing support requests.

There is also a big difference between ignoring people and taking on board what they're saying but disagreeing. I hear your objections to the sidebar. I disagree, I have also explained why I disagree. It doesn't mean that I don't acknowledge the fact you don't like the sidebar, but the thing is, we're not trying to build your perfect software. We're trying to build OUR perfect software, and that doesn't mean catering to your exact requests.

In SMF's case, they weren't particularly interested in what we had to say, despite being more than just community members. Nao worked on the single most popular SMF mod, plus contributed hundreds of bug reports. I wrote their bug tracker, spent months reviewing community mod submissions and did literally thousands of support topics, and both of us were almost on the SMF development team in one way or another. I'd say that would tend to qualify us for having some say in how things are run, yes?

(Also note that 2.1 is only just into alpha, with far less changes than we've made, and a new development team since 2.0 final was released. And even then, the 2.0 / 2.1 dev team has forked off into their own software. Because the team fundamentally is toxic, it continually pushes out the people who have the drive to actually do anything.)Except you should understand (being a programmer), as I've alluded to, that it just isn't that simple.

So you hide the sidebar. You now have to process that decision on every page, in a way that you don't currently. We also need to rewrite everywhere that pushes content into the sidebar, to now not push it into the sidebar, which means we have to find somewhere else to put it. Which in half the cases is also going to mean writing new templates for them to now be horizontally arranged rather than vertically stacked, or just simply not performing the queries for it in the first place.

This also means that the plugins that already exist which use the sidebar (several come to mind) will all need to be heavily modified to do all the same logic, turning one into two or even three states (on/sidebar, on/elsewhere, off). All because you want an option to turn something off.

That's what I mean about consequences - to you, it's one line of HTML, to us it's at least a day's work, and frankly, I've got far more important things to be doing for Wedge's benefit like finishing the things that I've started.Not in the core. It's not impossible to do, though. But we find it makes the central content far too narrow, which is why we don't do it.