Wedge

Essentially it was some nonsense about automated tools generating code and if there was a generator indicated, it would relax certain validation rules or something. Nao mentioned it, I just threw my hands up with a WTF gesture and am presently waiting for the powers that be to get their heads out of their posteriors.

Yes, I'm sure there are errors. But hey, it's alpha software, with new commits most days, there ARE going to be issues, especially when using a tool that by its own admission is probably buggy, against a standard that won't be a standard for another year at least if ever...

According to what validator, exactly?

Have they changed their minds (again) about what is valid and what isn't? As it is, we're waiting for them to change their minds, yet again, about certain attributes being required when a certain meta tag is (or is not) present.

I would strongly suggest not using WP with Wedge. The two will not play nicely and in all honesty there will end up being little reason to have WP when Wedge will be able to cover the bases (and do it *much* more efficiently)

Wait, what? Am I seriously reading this correctly?That makes a lot of sense :) Actually there aren't many places we do export XML, it's more internal use. I did contemplate - briefly, mind - using JSON for the plugin manager but the one thing XML does that JSON doesn't cleanly do is be able to attach attributes to elements in a multidimensional fashion, e.g. <element attr="value"> without making it another level of nesting.

Also, you're not the Wesley Crusher of gzipping, you're the Data of gzipping. Being the Wesley Crusher makes you the smart-arse no-one likes (and one person even told him to his face that it's a good thing he's cute otherwise he could be obnoxious), whereas being the Data of gzipping means it's cool to be intense about it.

(14 files, 6KB)

Revision: 1896
Author: arantor
Date: 04 February 2013 03:05:37
Message:
! Legacy code, missing check being called properly, stupid function not working as intended. (Security.php)

! One less variable injected inline. Potentially more could be done here but it's not pleasant. (Post.template.php, post.js)

! Profile now displays banned status properly, and some language cleanup as a result. (Profile-View.php, Profile.template.php, language files: index, Profile)

! Deleting accounts should clean up matching bans that would no longer apply. (Subs-Members.php)

! Newsletters shouldn't be touching the existing table, as such. If they're banned through username or their email, their account should be full banned anyway, no need to requery for that stuff, at least not there. (ManageNews.php)

! The old ban tables are now gone. Good bye. Good riddance. (install.sql, Class-DBPackages.php, ManageMaintenance.php)
----
Modified : /trunk/Sources/Class-DBPackages.php
Modified : /trunk/Sources/ManageMaintenance.php
Modified : /trunk/Sources/ManageNews.php
Modified : /trunk/Sources/Profile-View.php
Modified : /trunk/Sources/Security.php
Modified : /trunk/Sources/Subs-Members.php
Modified : /trunk/Themes/default/Post.template.php
Modified : /trunk/Themes/default/Profile.template.php
Modified : /trunk/Themes/default/languages/Profile.english.php
Modified : /trunk/Themes/default/languages/Profile.french.php
Modified : /trunk/Themes/default/languages/index.english.php
Modified : /trunk/Themes/default/languages/index.french.php
Modified : /trunk/Themes/default/scripts/post.js
Modified : /trunk/root/install.sql


@ Yes, this is almost entirely ban related. But since each of the different bits is a small part of the whole I delineated it, more for my reference later. (Thumbs down for Caesarness: the tables were not to survive. They have been tossed to the lions, who found them a bit chewy.)

(13 modified, 2KB)

Revision: 1893
Author: arantor
Date: 03 February 2013 03:27:05
Message:
! Did I mention that I love the @language embedding into script files? Set a default string from index, set it once and never have to explicitly set it again in any of the multiple places it is called (unless you *really* want to). All this for the 'delete item' help text on the auto suggest... it's the same everywhere, so just embed it in to the suggester as a default! It bugged me, mkay? (all files)
----
Modified : /trunk/Sources/ManageBans.php
Modified : /trunk/Sources/media/Aeva-Gallery2.php
Modified : /trunk/Sources/media/ManageMedia2.php
Modified : /trunk/Themes/default/ManageBoards.template.php
Modified : /trunk/Themes/default/ManageMaintenance.template.php
Modified : /trunk/Themes/default/ManageMembergroups.template.php
Modified : /trunk/Themes/default/ManageNews.template.php
Modified : /trunk/Themes/default/ManagePaid.template.php
Modified : /trunk/Themes/default/Media.template.php
Modified : /trunk/Themes/default/PersonalMessage.template.php
Modified : /trunk/Themes/default/Profile.template.php
Modified : /trunk/Themes/default/scripts/pm.js
Modified : /trunk/Themes/default/scripts/suggest.js


@ And since it's now embedded in the suggest file, it will not only be gzipped and cached, it no longer has to be inlined into all the pages it's in, or declared in those pages where used. I would imagine that's actually a tidy little saving everywhere that uses the auto suggester, all in all. Every little helps.

I can see entirely where you're coming from - I always have been able to. The problem is that your envisioning of it does not tie up to the reality of how it works - even you yourself see that it's impossible for a theme to have total control over mods because of keeping up with mod changes.

There is actually *more* power in Wedge's theme engine than in SMF's, vastly more, and it enables plugins to be more flexible by moving blocks of content around, inserting new blocks of content between them. None of that's changed. And plugins have more ability to play nicely with themes now.

I guess what frustrates me about this topic is that we seem to be retreading the same ground every 6 months and nothing has changed in that time, at least not in the practical world.

Your ideas are grand, but unfortunately I don't see how they can possibly stand up to real world use. That's fine if what you're doing is solely for your own use, when you don't have to care about real world users, but we have to.

Go and look at al the platforms out there, every single forum system has the same problems, and the same problems creep into WordPress too... and I hope you're not going to tell me that WordPress is 'less flexible' than SMF because we both know that's not true either. WP gives theme authors the nearest thing to total control and that causes almost as much of a mess for plugins as what SMF does. More, in some respects, because it can be hard to nail down and make sense of it.

I'm sorry, I have to ask this because it's been bugging me: if you understand we have a firm direction (and one that hasn't changed in over a year, I might add), why keep bringing these things up every few months? You don't want to change our minds, you say, and yet by bringing it up again and again, you're trying to. Or at least, I don't understand why you're bringing it up again and again, when you know it's not going to change.

We did take in to account what you were saying; that's how the template skeleton came into being at all. It was the only way we could think of to find any kind of compromise between the two because we believe the two need to work together - and it's the nearest we've got to that point. I'm sorry that you're so unable to understand that we have to have this compromise between the two but that's the curse of working on something that is intended for widespread distribution, not a hobby project.[1]

1.	I do not wish to be rude, but I don't know how else to classify bloQs or ViennaBBS or whatever it is called, it seems like it is a fine hobby project, which is a great thing in itself, but that has never really been our goal with Wedge if we're honest.

jQuery's documentation has always been a bit sub-par, I thought. Using .prop consistently, if it's an option, would likely be easier.