Oh goody, let's hide front end stuff in the back end coding! May 28, 2016, 04:42:13 pm You lot love doing this. I need my SMF siggy over here:Quote"Oh hai! We haz awesome back end logix!" does happy dance"Cool. Hey I wanna do ***** on the front end.""No can do.""Why not?""Coz we haz awesome back end logix!" happy dance again"Meh."Anyway, I was taking a look at index.template.php and found this bit:Code: [Select] <div id="wrapper" class="wrapper"> <div id="upper_section"', empty($context['minmax_preferences']['upshrink']) ? '' : ' style="display: none;" aria-hidden="true"', '>'; call_template_callbacks('uc', $context['upper_content_callbacks']); echo ' </div>';Ok, so apparently this is done to enable people to hook in extra stuff to that area, and have it handled by the same collapse/expand function. That's my guess anyway, since I can't see any other reason to do it.The catch is that from a themer's perspective there is no indication of what is covered by upper_content_callbacks. It's all pretty opaque, and they'd have to go digging in the back end to figure it out. Then, if they want to change something in the theme, AFAICT they would have to ditch function template_uc_news_fader() and replace it with another function to get something independent of upper_content_callbacks.Ok, so what happens if function template_uc_news_fader() is ditched? Will anything break, due to sources expecting it to be there?
Re: Oh goody, let's hide front end stuff in the back end coding! Reply #1 – May 28, 2016, 06:26:46 pm There is almost nothing hidden in source... actually nothing at all.The whole function is at the beginning of index.template.php, so you should be able to tell me. https://github.com/elkarte/Elkarte/blob/e7e6d32ca24365a11dde18f936dc2ff86dd52dc7/themes/default/index.template.php#L95Let's say you don't want the news fader? You have at least two ways:1) make an empty template_uc_news_fader2) remove the function from your index.template.php altogether.You want the news fader somewhere else?Pick 1 or 2 and then put the news fader wherever you want.You want to make some other block showing the news fader and some of the functions some addon added to the template in the header? You can do it that way without even caring if the addon is installed or not. Use another call:Code: [Select]call_template_callbacks('my_own', $context['upper_content_callbacks']);and then create as many functions as are the "features" you (themer) want to have (if installed by the admin) in the theme:Code: [Select]// this removes the news fader from the topfunction template_uc_news_fader() { return; }// this adds the news fader in "my_own" positionfunction template_my_own_news_fader () {...}// this removes the awesome addon from the topfunction template_uc_awesome_addon() { return; }// this adds the awesome addon in "my_own" positionfunction template_my_own_awesome_addon() {...}if the awesome_addon is installed the template will be used, otherwise it will just be ignored (okay, this provided the addon was installed before the theme and the theme has a template file named the same as the addon template file, to avoid function names conflict).Yes, of course for you would be much better to hard-code the html into your own code, no arguing. But from time to time, it's nice to think also to end users. Little final rant.Spoiler (click to show/hide)I guess it's the never ending fight between you and me (now that Norv is no more around ).I'm giving you tools to do whatever you want without admins having to bang their heads on the table because a search and replace doesn't work, but you keep telling me it's garbage because HTML rules.The only thing filled in source if the list of "blocks" displayed in each position, but I wonder why you complain about an array here when any portal fills the front-end with tons of stuff coming from the back-end that no themer can change in any way (mostly, because it's not really true that one as well, even though it's hardly as easy to hide/move portal's blocks from the template as it is in this setup).
Re: Oh goody, let's hide front end stuff in the back end coding! Reply #2 – May 28, 2016, 10:26:51 pm Ok, fair nuff. I suppose this should have been in Support rather than Development. Move it if you like.I think what you've posted makes sense, but I'll have to frig around with it and try some stuff.
Re: Oh goody, let's hide front end stuff in the back end coding! Reply #3 – August 21, 2016, 03:34:19 am I can see Antechinus's point here: it does make it a little hard to figure out what each addon will be delivering. But it also allows the addons to get into the theme without messing with the template, and it allows for tidier subtemplates(in other words: the callbacks within the theme itself)As I laid out in http://www.elkarte.net/community/index.php?topic=3972.msg28271#msg28271 I think you can have both cake and eat it too lol, by expanding the callback function, allowing the themer to pick and choose each callback for easier placement, but also allow it to put the output from unknown addons somewhere where he can control it better. In addition adding some HTML code before and after each callback allows for keeping things under wraps. Anyway, this was coded yesterday..no big field testing yet, I need to try out several of the addons and preferably those that use the callback function.I can easily see this callback being useful in other templates too though, I spotted use in index,boardindex and stats templates so far.
Re: Oh goody, let's hide front end stuff in the back end coding! Reply #4 – August 21, 2016, 03:56:11 am Yes, it's indeed underused. I think I added it on a whim because it looked better.Anyway, it's still only a simple "bit", make the theming really flexible will (still) take a lot of work.