Wedge

rev 987 (the big layer rewrite.)
(27 files, 77kb 8-))

+ Rewrote the template layer/subtemplate system from scratch and implemented a new 'skeleton' system, where the theme defines the desired layer/subtemplate structure with pseudo-HTML, and skins can freely change the order of the blocks. Layer functions are no longer mandatory, as layers can now be used simply as easy ways to keep multiple subtemplates in the same place. (Load.php, Subs-Cache.php)

+ Added loadLayer() function, which handles adding layers to the skeleton. Two positioning options are allowed for now (parent and child), but more will come in time. I'm also listing various files affected by layer changes. (Load.php, ManageAttachments.php, ManageMedia.php, ManageMedia3.php, PersonalMessage.php, Profile.php, Security.php, SSI.php, ManageAttachments.template.php, Profile.template.php)

* As a note; the main layer is now next to the top layer, when it used to be the top layer's parent. A new layer was added on top of them, anyway. (Subs.php)

* Rewrote hideChrome() to the new system. Its parameter now accepts three variations: empty means that the template will handle everything, from HTML headers to content. 'html' means that we only want the HTML headers, the body tag and the content. Specifying another string will behave like 'html' but will add an extra layer right before the content. (Subs.php, unittest/index.php, Aeva-Gallery.php, ManageBans.php)

* Split the wedge_cache_css() function into two different functions, so that skin options can be retrieved early on, and actually CSS caching is still performed at the last minute. May actually be a bit faster, because Wedge will no longer try to load parent CSS when a child is a replace-type skin. (Subs-Cache.php)

* Changed the Warm layout through a skeleton override, to allow for the sidebar to be shown on the left side of the screen, rather than to the left side of the content area (below the header). (Warm/skin.xml, Warm/index.css)

* Always define WIRELESS_PROTOCOL to wap2 when WIRELESS is defined, because it's the only one we have. Unless we start implementing support for iMode again (ah ah), I'd suggest we rename all of these subtemplates to get rid of the prefix... (index.php)

- Deleted the theme_layers feature because, you guessed it, it's useless now we have the skeleton code. (upgrade.sql, JSOption.php, Load.php, Subs-Members.php, Themes.php)

* Saved a few bytes off the noi_resize() function. Does it look like I'm obfuscating it? (index.template.php)

! Syntax error. Another one of the 'last minute commits'. (Class-Editor.php)

! $modSettings wasn't globaled in a function, causing OpenID to always fail. (index.template.php)

! Media upload page wouldn't validate, because an <input file> had a size parameter, which is no longer valid in HTML5. (Media.template.php)

* Shortened the PHP code in files when using the filesystem cache. It only saves a few bytes, but I see no reason to waste these bytes when you're never going to read them. Also no longer calling die() when WEDGE is not defined: it just won't load the cached data. (Subs-Cache.php)

* Renamed theme_linktree() to template_linktree(), and on the contrary, template_header() to start_output(), and removed template_footer(), because we really should avoid using template_* for anything other than an actual template function, and theme_* for anything that is a real subtemplate. (SSI.php, Subs.php, Xml.template.php)

* Split start_output() into two functions. The first initializes the output as expected, and the second is called if we're going through the top layer rendering process, instead of the previous method (done when iterating the _above list). This is totally untested, unlike the rest of this huge commit. It'll probably be the first thing to break. Used the opportunity to add import.php to the list of security files. (Subs.php)

Layers have always been frustrating... And one-dimensional.
I can't believe SMF got away with it for so many years -- unlimited nested layers, but only one sub-template in the entire page...! It's one of the first things we changed in Wedge -- adding support for multiple sub-templates. Although by now, even that sounds a bit limited, now that the skeleton fixes so many things.
Heck -- I no longer have to rely on a hack to support sidebars! NO HACKS! What do you say :lol:
And skins can remove the sidebar altogether without breaking anything. Haven't tested, but it should be doable... (They can also simply move it to the bottom of the screen and re-style the sidebar area to allow for a horizontal layout, of course. I'd recommend that, because getting rid of the sidebar is okay, but its content...? Not so much.)

BTW, I'm currently pondering whether I should rename some of the things in the template system.

Current: Sub-templates. Suggested: Blocks. Rename loadSubTemplate() to loadBlock().
Current: Blocks. Suggested: Macros, or Snippets. Ultimately, a 'macro'[1] better represents what it does: suppress the need for boring repetition of a more-or-less large part of code, allowing for the dynamic replacement of certain values within it.

Well, at least we call these 'macros' in French. Dunno if it's the same in English but it seems to be the case...

1.	Phonetically, it also translates to "pimp" in French. What an interesting language :lol:

BTW I totally broke the editor with a last minute change (around the 'last minute header' line, the irony :lol:), it's just missing a parenthesis, I'll commit that next of course, but it'll have to wait until the template code is ready...

Oh, and I've removed support for 'theme_layers'. It's become a non-issue since the introduction of the skeleton. All in all, I think the code overhead is pretty much on par with the template_layer feature.

Cache vars mostly use single-dimensional string arrays so it sounds like json_decode is at a disadvantage here.
Too bad, I liked the fact that it made for such sort cache vars, too :)

A few of my recent attempts... I didn't think they were worthy of being posted, but what the hell -- you don't have to comment anyway :P
(First one is best viewed on a darker background, obviously...)
:edit: Added a darker background on it.

Oh well... I really don't remember a thing of it. We've manipulated dozens of thousands of lines of code, it's nothing surprised that my memory banks have reached their natural limit... :lol:

Still, since you seem to remember how it works, please have a look at the content-disposition headers for me in AeMe :)

(Another 'cleaning up my local install' commit...)

rev 986
(7 files, 10kb)

! Not sure where (I'm busy!), but it looks like the editor class may be called at different points in time during rendering, making it necessary to use $context['header'] as well. Also micro-optimizations. (Class-Editor.php)

! Fixed syntax error in a comment... Well, it does suggest to uncomment it after all. (ssi_examples.php)

! A few lines of code needed to be turned into loadSubTemplate(). (unittest/index.php)

! Just because the theme hasn't finished loading doesn't mean the text strings aren't already loaded... Well, at least I met such a case during testing. (Errors.php)

* Commenazi and other boring changes. (ManageSmileys.php, Reports.php, index.english.php)

It's not shot to hell... It only adds below the end of the body. If it was shot to hell, I'd be out fixing it... :lol:
No, don't touch $db_show_debug, I always have it enabled, even if I don't use it, while ?debug would kill my layouts... :^^;:
I actually didn't understand anything about layers and sub-templates before I started working on Wedge... Yikes.
Which is one of the reasons I thought that skeletons could sound more logical to newbie modders and themers.How would you see them have the 'last word'?
Adding a function somewhere at the end that allows for the theme to check for integrity...? :^^;:

Oh, which makes me think -- there is technically nothing that prevents me from doing all layer/sub-template operations directly on the pseudo-HTML that I provide in $context['skeleton']. I only converted it to an array to make it more 'logical' for parsing by users, but if I add enough wrapper functions, I can do everything myself with regular expressions...
I don't know what's best for this. I'm currently sticking to the array solution, but I guess it's not going to take a long time to rework everything into using a HTML string if needed.Well, I don't really have a suggestion on how to fix this (plus, Pete seems to have the problem in WedgeDesk itself ;))
Do you have anything...?
Multiplying the number of layers, maybe? And putting your positioned stuff in one of the top-level ones, and hoping that mods will only built upon lower-level layers?But, doesn't SMF already allow themes to know that...? It's all in $context['template_layers'] AFAIK...? And it's easy than Wedge, because template_layers is a single-dimensional string, basically a set of Matryoshka dolls that can easily be analyzed, while Wedge now has a more complex multi-level structure. So I don't know that my thing will be 'the' solution at all for this kind of issue...

I'm all ears though, if you have any suggestion, however little it is. I'm not building this system for myself but for themers -- no, not themers -- for *designers*. To give complete freedom on the layout, which usually isn't possible without redoing a new theme, i.e. getting into compatibility problems.I may not be a 'designer', but I'm a good listener when it comes to feature implementations, you should have suggested this kind of change long ago ;)