Wedge

It'll look better when it isn't buggy :P

But there are some other interesting side effects to converting to Wedge, like being able to use weToggle, so the collapsible areas are now animated, which is cool, and the code is getting shorter where I can remove so much of the cruft where I don't have to try and support both Curve and Core based themes. So much time was spent just removing Core compatibility code that it's unreal, far more than converting to our meta code for styling purposes.

Yes, I did, a long, long time. The idea was to harmonise the headers being sent because there were different headers being sent in the hopes of sanitising the filename into UTF-8 even if it wasn't already, for browsers to cope with. We're UTF-8 only, and have been for a long ol' time, so it ceased to be an issue.

Certainly it predates Media being integrated, and it may even predate Dlattach.php becoming its own file, that's how far back it was.

And IIRC you were the one who asked me to look into it at the time because you thought we didn't need multiple lines of headers...

Protip: examine the HTTP headers.

If there's no Accept header, chances are it's a dodgy request - or it's Baidu.

loadTheme should always be called, at least. But if $_REQUEST['xml'] is defined, hideChrome() is called, the Xml template is loaded, and the rest of the pure theme stuff (most importantly, loading any required templates and initialising template layers) doesn't happen.

After that, it sets up jQuery, and looks for the init subtemplate in a theme, sorts out blocks, then just wanders off on other stuff like dealing with scheduled and imperative queues, the mail queue and stuff like that, nothing that should be a problem here.

Anything in the error log?No, any subsequent layers are children of the existing layer. Thus if you add a new layer to the default, you get html_before, body_before, newlayer_before, main, newlayer_after etc.Yes, but we don't always want to layer things, which is where it gets complicated. The way I'd envisage using it normally is to have some content, encapsulated in markup (either a block or some other container) and inject that into the existing structure, which wouldn't necessarily constitute a layer.

The really important use is to be able to inject content into the sidebar, which notionally requires adding to the list of templates to be called by the sidebar layer, rather than creating new layers.[1]There isn't a particularly quick way of doing it, to the best of my knowledge. All the methods for accessing arrays (even more exotic options like array_replace in 5.3) are for dealing with the values not the keys.

What about something like:

I don't know how efficient that'd be versus building a new array from scratch as a product of regular iteration of the original array, but that's the approach that occurs to me, anyway.Oh, you already did it, heh.The facility would be useful, even if it ends up being underused, though adding a template to the end of a layer is significantly more important in the long run.

You and I are actually in agreement, though it might not look like it. You're right, it should need all 4 options, which are effectively: outside, inside, before-item, after-item.

In your examples, the first is before-item (it's before <output />), inside, outside (all considered relative to main), and the only item that's lacking is after-item, because positioning of templates is potentially quite important.

Remember: forcing everything to be actual layers is potentially a headache and one I don't want to repeat. See, if you provide the ability to place content with those 4 options, it doesn't matter if it's a layer or a self contained item.

The same logic should cover for adding <extra-content /> after <output />, the only difference is that extra-content isn't an array signifying a layer but a self contained item, right?Fair call, I do the same :lol: Like I said, I was only considering it being part of db_show_debug, but it really should be in the debug menu (and I'd probably remove it from URLs and sessions otherwise if it were a modSetting)Please please please leave it as an array. It can be built from a pseudo markup string in the skin file but it really should be an array internally because it's much faster to inject items into an array than it is to use string munging.This is where themes and mods are always going to have problems, because there is no possible way that you can expect everything to work in a meaningful manner, there just isn't.[2]

What we can do, however, is be intelligent about it. The default theme has a sidebar. I have no problem with the theme indicating through some kind of variable that it provides a sidebar. Then WedgeDesk can check to see if a sidebar is given, and if it is, use it, otherwise I can reimplement the sidebar type bits that I had before (as in if the theme doesn't provide for one, I can)

Then you get more clever, because if/when a portal comes along, it can look at that too - if the theme provides a sidebar, make use of it, but if not, the portal can create one. It'll take a bit of co-operation to make it work but instead of going it alone as much as historically happened, I see no reason why we can't be a bit smarter about it.From my standpoint, I think it is, because it provides the core with the facility to let designers be a lot more free - and it's not like it's some mythical resource.

All the time it's supported and there are add-ons using it rather than hacking templates about, it'll be an improvement. Sure there are going to be incompatibilities but that's a fact of life: it's going to happen that some things just don't play nicely. This, however, will really minimise that being a problem, IMO.Themes dictate what layers they want used, which is typically html and body. They're the ones calling the shots, it's not like there is default skeleton in place that they can make use of - or totally ignore in favour of their own, and that's it.

It's not like there's any kind of structure to it, other than a fairly limited approach, but even that isn't used that much. By making it more powerful, and proceeding to actually *use* that power a lot more, I think we'll see more and more examples of it.

But ultimately it's going to rely on a certain set of contractual obligations - like I mentioned above with the 'supports sidebar' concept. Themes are going to need to indicate if they provide these things or not, and if not, mods that want to use them will need to do something else to accommodate it (or risk the outfall of incompatibility), and that's something that's just going to have to happen. We can't (and, IMO, shouldn't) dictate that every theme has to support a sidebar, it's not realistic to expect that.

1.	Even if it's physically implemented by new layers, the notion is that it would be a single encapsulated template within the sidebar layer, if that makes sense.
2.	Hint: even the magical holy fucking grail that is WordPress[1] has this issue where themes have to provide support for common widgets and vice versa.  1.  I meant that sarcastically. WP is not a holy grail in my eyes.

Revision: 985
Author: arantor
Date: 11:22:43, 08 September 2011
Message:
! Allow the richedit component to style individual buttons if they so desire, not just the post button. (Class-Editor.php)
----
Modified : /trunk/Sources/Class-Editor.php


@ Something out of WedgeDesk, really. Where we're styling buttons in various places, I have a richedit control that has both a save and a delete button, and wanted to style the delete button like all the others. Really not a big thing but something I wanted to do :)

Baidu is a horrifically vicious bot. Where Google might send two or three requests at a time, I've seen Baidu send 20.

Interestingly, because of default Bad Behaviour checks, Baidu is actually currently blocked, and I'm honestly not sure whether I should change that or not - and I'm more inclined not to change it for the most part.

Just thought I'd share this particular oddity. I have no idea why the sidebar is here.

(Nao: the sidebar appears slightly to the right of where it's supposed to be when the page loads - and it thinks it's in the collapsed position, so hovering on it pushes it out to here. This is the thing I already mentioned and I'm willing to bet it's caused by the abuse of template layers and divs to create that left menu.)

Sounds like a very awesome amount of functionality and very, very flexible too :)

Can't wait to actually see it to play with.