I've only seen this quickly, it seemed to me but it seems like XML will bypass many things in loadTheme() or something...
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?
any subsequent layers added will become parents of the earlier added layers. It's not a big problem to me but I don't think SMF does it in that direction... (Does it?)
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.
When exactly do we want to add a layer, and what for? Generally it's because we want to add something around the code being executed.
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.
Also, I'm having fun (ah ah... not exactly) trying to figure out how to quickly rename an array key.
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:
$keys = array_keys($original_array);
$values = array_values($original_array);
foreach ($keys as $key => $value)
if ($value == $key_to_find)
{
$keys[$key] = $key_to_replace;
break;
}
$new_array = array_combine($keys, $values);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.
Okay, renaming keys was easy enough, surprisingly... And fast.
Oh, you already did it, heh.
Of course I can include an option to do any of the three, but I'm sure there's going to be at least one option that never gets used... And we're bound to find people complaining they can't add an empty layer at the *end* of an existing layer...
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?
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...
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)
but I guess it's not going to take a long time to rework everything into using a HTML string if needed.
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.
Well, I don't really have a suggestion on how to fix this (plus, Pete seems to have the problem in WedgeDesk
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.
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.
So I don't know that my thing will be 'the' solution at all for this kind of issue...
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.
But, doesn't SMF already allow themes to know that...?
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.
