Skip to main content
Topic: Unify themes and mods behaviour? (Read 17448 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

Re: Unify themes and mods behaviour?

Reply #15

Quote from: TestMonkey – Well. To implement functionality, addons use hooks. (lets say it's usual)
To implement functionality, why would themes break that
Easy answer: because it's quicker and cleanner to code, and will give better performance. To me, those sound like good reasons. It depends what you want to support though.


QuoteWe're talking about trying to make the core approach give people tools to do the job differently. What they do with the tools is up to them in the end, but that's not really the point.
Fair enough.


QuoteBut I agree that "if it's too complicated then I won't do it", this is a fair point. Lets make it less complicated (if it is).
What is currently complicated about hooks? (I has a couple beefs tbh).
What is complicated about setting variables to $context?1

For the record, this is the recommended standard for core: to implement functionality separately from presentation of the functionality. (where 'recommended' = 'required').
This is the recommended standard for addons: to implement functionality separately from presentation of the functionality.
(where 'recommended' = 'recommended').

In the context of this discussion, I will propose the following statement: themes are about presentation of existing functionality, but if they implement new functionality, then they should do it separately (at file/code design/implementation level) from the presentation of the functionality.
Ok just for examples, take multi-option themes. So we're inheriting the 2.0.x theme variant system, which is good up to a point. The point comes when some silly bugger decides to get creative. This is, basically, what themes are about, and it's also why I fight against the "let's put everything in Sources" stuff. For someone who is into code architecture, it probably seems like a great idea to put as much as possible in Sources, whereas for themers it's the exact opposite: they want the absolute minimum locked away in Sources.

Anyway, for the latest guinea pig I wanted several layout options as well as several background/colour options. I've gone for four of each.* If you try to do all of that with the existing theme variant system, it becomes a wheels within wheels scenario when you want to choose your preferred option. The theme would have to be set up to take account of all the permutations, which would be a PITA. Simple way to do it: allow people to choose their preferred background independently of the layout option.

That's what I've done, and it can be done in the template with very little code. This is obviously new functionality, but I don't see any reason to have to make it a separate mod.

*BTW, the reason I did this was because I've been thinking for some time that the variant system is ideal for offering different layout options, but that didn't mean I wanted to restrict colour/background options either. I want it all and I want it now. :D
Last Edit: December 26, 2012, 03:24:01 pm by Antechinus
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Unify themes and mods behaviour?

Reply #16

Thanks for the explanation and case scenario. :)
OK, I admit that the percentage of blood left in alchohol at this exact time is quite low. But I'm sure this stands: can you please share the code (or give us a link to it), so we can see the problem of this functionality on the code, concretely?

Disclaimer: I actually am not sure I am well aware of the latest fixes/changes Spuds and Ema did for multi-variant themes, and I would need to look closely into it anyway.
The best moment for testing your PR is right after you merge it. Can't miss with that one.

Re: Unify themes and mods behaviour?

Reply #17

Ok, but said guinea pig is 1.1.x, not 2.0.x or 2.1 or the dreaded Los el Cartos Amigos. Code is quite simple though. It's the same basic idea used in all 1.1.x multis, and in some of Bloc's themes for background pickers. Goes like this:
Code: [Select]
	 // Layout changer.
if(!$context['user']['is_guest'] && isset($_POST['options']['theme_layout']))
{
include_once($GLOBALS['sourcedir'] . '/Profile.php');
makeThemeChanges($context['user']['id'], $settings['theme_id']);
$options['theme_layout'] = $_POST['options']['theme_layout'];
}
elseif ($context['user']['is_guest'])
{
if (isset($_POST['options']['theme_layout']))
{
  $_SESSION['theme_layout'] = $_POST['options']['theme_layout'];
  $options['theme_layout'] = $_SESSION['theme_layout'];
}
elseif (isset($_SESSION['theme_layout']))
  $options['theme_layout'] = $_SESSION['theme_layout'];
}

// Background changer.
if(!$context['user']['is_guest'] && isset($_POST['options']['mypic']))
{
include_once($GLOBALS['sourcedir'] . '/Profile.php');
makeThemeChanges($context['user']['id'], $settings['theme_id']);
$options['mypic'] = $_POST['options']['mypic'];
}
elseif ($context['user']['is_guest'])
{
if (isset($_POST['options']['mypic']))
{
$_SESSION['mypic'] = $_POST['options']['mypic'];
$options['mypic'] = $_SESSION['mypic'];
}
elseif (isset($_SESSION['mypic']))
$options['mypic'] = $_SESSION['mypic'];
}

}

// The main sub template above the content.
function template_main_above()
{
global $context, $settings, $options, $scripturl, $txt, $modSettings;

// Show right to left and the character set for ease of translating.
echo '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"', $context['right_to_left'] ? ' dir="rtl"' : '', '><head>
<meta http-equiv="Content-Type" content="text/html; charset=', $context['character_set'], '" />
<meta http-equiv="X-UA-Compatible" content="chrome=1" />
<meta name="viewport" content="width=device-width" />
<meta name="description" content="', $context['page_title'], '" />', empty($context['robot_no_index']) ? '' : '
<meta name="robots" content="noindex" />', '
<meta name="keywords" content="cemb, ex muslim, former muslim, council of ex-muslims, leaving islam, discuss islam, islam, murtad, apostate, sharia, koran, quran, hadith" />';

// Any layout set by user?
if (isset($options['theme_layout']))
$settings['theme_layout'] = $options['theme_layout'];

// If not set, or if not allowed to set
if(!isset($options['theme_layout']) || (isset($settings['allow_layout_change']) && $settings['allow_layout_change'] == 'no'))
{
// Defaults.
($context['browser']['is_touchscreen']) ? ($options['theme_layout'] = 'Mobile') : ($options['theme_layout'] = isset($settings['theme_layout']) ? $settings['theme_layout'] : 'Standard');
$settings['theme_layout'] = $options['theme_layout'];
}

// Any backround set by user?
if (isset($options['mypic']))
$settings['mypic'] = $options['mypic'];

// If not set.....
if(!isset($options['mypic']))
{
// Defaults.
$options['mypic'] = isset($settings['mypic']) ? $settings['mypic'] : '1';
$settings['mypic'] = $options['mypic'];
}

// Load stylesheets before javascript. Avoids FOUC on page load.
echo '
<link rel="stylesheet" type="text/css" href="', $settings['theme_url'], '/style_Standard.css?116" />';
if ($settings['theme_layout'] !== 'Standard')
echo '
<link rel="stylesheet" type="text/css" href="', $settings['theme_url'], '/style_' , $settings['theme_layout'] , '.css?116" />';

Then it just has a couple of selects anywhere else for the pickers. Now of course you could do this with the variant system. In that case you'd just decide which function you wanted to run via variants, and which one you wanted to run via the custom code (one instance of, instead of two).

Selects are coded like this:
Code: [Select]
	// Layout selection.
if (isset($settings['allow_layout_change']) && $settings['allow_layout_change'] == 'buttons')
{
echo '
<form name="layout_select" action="' . $_SERVER['REQUEST_URL'] . (strpos($_SERVER['REQUEST_URL'], '.php?') !== false ? ';' : '?') . '" method="post">
Layouts&nbsp;
<select size="1" name="options[theme_layout]" onchange="submit()">
<option value="Mobile" ', (!empty($options['theme_layout']) && $options['theme_layout'] == 'Mobile') ? 'selected="selected"' : '' ,'>Mobile</option>
<option value="Smallscreen" ', (!empty($options['theme_layout']) && $options['theme_layout'] =='Smallscreen') ? 'selected="selected"' : '' ,'>Smallscreen</option>
<option value="Standard" ', (!empty($options['theme_layout']) && $options['theme_layout'] ==   'Standard') ? 'selected="selected"' : '' ,'>Standard</option>
<option value="Widescreen" ', (!empty($options['theme_layout']) && $options['theme_layout'] == 'Widescreen') ? 'selected="selected"' : '' ,'>Widescreen</option>
</select>
</form>';
}
// Background selection.
if ($settings['theme_layout'] !== 'Mobile')
{
echo '
<form id="background_select" name="background_select" action="' . $_SERVER['REQUEST_URL'] . (strpos($_SERVER['REQUEST_URL'], '.php?') !== false ? ';' : '?') . '" method="post">
Styles&nbsp;
<select size="1" name="options[mypic]" onchange="submit()">
<option value="1" ', (!empty($options['mypic']) && $options['mypic']=='1') ? 'selected="selected"' : '' ,'>Light stone</option>
<option value="2" ', (!empty($options['mypic']) && $options['mypic']=='2') ? 'selected="selected"' : '' ,'>Dark grunge</option>
<option value="3" ', (!empty($options['mypic']) && $options['mypic']=='3') ? 'selected="selected"' : '' ,'>Evening sky</option>
<option value="4" ', (!empty($options['mypic']) && $options['mypic']=='4') ? 'selected="selected"' : '' ,'>Dark sunset</option>
</select>
</form>';
}

The !Mobile conditional is just because there's no point in a pretty background on a phone, because you can't see it anyway. So for phones the css just sets a basic white background on body, regardless of which background option is set.
Last Edit: December 26, 2012, 04:14:03 pm by Antechinus
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Unify themes and mods behaviour?

Reply #18

Quote from: Antechinus –
Quote from: emanuele – Well, you cannot assume we are writing a forum for your own use. :P
We are writing it for anyone and it should have "a way to work" that works.
Yeah sure. I get that. I'm just saying that people should still have the option to code things how they like, without being locked into one path because somebody thought that was the right way.
Then I'm not sure where the issue is.

In your own forum you can do pretty much whatever you want. We are not arguing about what you do with your own site/code. We are arguing about coding standards for all the people out there that would like to build something on top of elkarte and make it compatible with an indefinite amount of other things.

Anyway, to have an idea of what means have "source" mixed in the template have a look at TinyPortal. Try to modify it. I tried and I can assure you it's not easy at all.
Bugs creator.
Features destroyer.
Template killer.

Re: Unify themes and mods behaviour?

Reply #19

Not sure what you mean with TP. I haven't really looked at the 1.0.x series of TP, but I find the earlier 0.9.8.x series quite easy to modify.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Unify themes and mods behaviour?

Reply #20

No, it's not.
SimplePortal is easy to modify and expand.
Bugs creator.
Features destroyer.
Template killer.

Re: Unify themes and mods behaviour?

Reply #21

Uhm, I have to agreed somewhat, TP is quite "compact" and could surely use some cleaning up in templates. The problem is that its layer upon layer of ideas, and some of them did not start as what they ended up as lol. Anyways, its a big mod and changes enough to warrant a fork IMHO. Its part of the reason I stopped working on it, my goals could not be set without making almost a total rewrite, especially on the way different layouts was made for block setups. The trouble was, as always, that SMF do not have support for doing things like blocks and panels that go around the main content. And thats perfectly fine...and explains why portals seem to do complex things just to add them lol. Take PortaMX, at least as complex as TP and a lot more mixing in templates + using the more challenging OOP programming..it even has a total rewrite of frontpage that overrides the normal theme lol, quite a annoyance for anyone making a theme for it. Anyway, Simpleportal adressed things much better so it can be done. I just didn't have the desire to wrestle TP into it. Plus the users would not have anything changed, the changes I did make always meant going back too after some time, for compatibility reasons...

But back to mods/themes, agreed with Antech about how its used..but its also that: many people change little things in themes, just a few does more creative stuff. Should Elkarte support the first or the latter? I suspect the answer is the first, and thats then logical to not add too much freedom in themes. Mods will be complex either way, since users don't change them - mod authors do.

Me, I WANT more freedom in themes. ;D But I have to make it myself lol, that I have long since realized.

Re: Unify themes and mods behaviour?

Reply #22

Yeah Ema and I may be talking about different things. I've been mainly concerned with changing the presentation/markup/css in the old TP, which isn't really any worse than anything else in SMF. Haven't gotten involved in trying to write new blocks for it, or stuff like that.

I agree that by default the idea should be to support the "no brainer" way of doing things, as far as possible. I'd just prefer to not make more advanced coders jump through hoops if they don't want to. If we can do the former without imposing the latter, that would be great.

And don't tell me that themers don't change mods. I do it all the time. :D
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Unify themes and mods behaviour?

Reply #23

Themers yeah...but not the typical admin I would suspect. :)

Re: Unify themes and mods behaviour?

Reply #24

True. I see the whole thing as very blurry. Take the choice between hover drops and click drops. You can argue that it's a change in presentation, or you can argue that it's a change in functionality. I'd say it's both.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Unify themes and mods behaviour?

Reply #25

Tracked: https://github.com/elkarte/Elkarte/issues/229

Just as quick note: I'm not sure when we get to more on this, as a priority. At this time it doesn't seem on the radar with a few exceptions? Not on the roadmap atm, afaict.
But this is a good example of one of those discussions for whose status, if you want to participate and keep tabs, will be in the tracker.
The best moment for testing your PR is right after you merge it. Can't miss with that one.