I seem to have stepped on a rather soar and grumpy toe, lol.
My only point was this:
It makes sense that the mobile theme is set to 'mobile' in the shipped config, witch it is. My issue is that if you remove the line, or leave the value blank, it does not make sense to me for the system to fallback to a value that I have never ever chosen (nor would ever choose). In my mind (and in all other systems I run, including i.e wordpress) removing the setting for mobile theme is the same as removing the use of a mobile theme (AKA not having a specific mobile theme, AKA fallback on the chosen main theme).
@vrijvlinder said:
Should Vanilla have to do everything for you?
This is exactly my point. If I have not chosen a mobile theme, I do not want Vanilla to choose one for me.
If this is a deliberate choice that feels logical to you, feel free to keep it as is. I was merely venting a suggestion based on my experience as a sysadmin with other php systems, that this feels like yet another of those coders' choices in a world where more laymen than coders uses web systems.
I have no need to discuss this further, no big deal. I'm sorry if my post was confusing, and that you felt the need to get so defensive about it.
@JohanRonstrom said:
I have no need to discuss this further, no big deal.
No discussion, just one explanation: if Vanilla reads from configuration it has a "sane" fallback - some value that made sense somewhere in the past. It must be "sane" in that it has a valid value - something that is not causing errors. So when there is no mobile theme given, it falls back to a working mobile theme. That's the logic behind it.
Vanilla simply doesn't assume that your main theme is mobile ready. If it will ever be the case that every theme is mobile ready, it would make sense to change that default, but until then, the fallback must be safe.
@R_J said:
if Vanilla reads from configuration it has a "sane" fallback
I'd argue that a default "mobile" theme is not saner than your own theme. I mean, imagine you have your own plugins and stuff that need to be properly dealt with by the theme. Is it better to load the default mobile and leave all that undealt with? I think that the default theme should go over the "mobile" one, because the potential damage of leaving "loose" DOM objets or miss some javascript code is worse than layout problems.
That being said, we are arguing over minor differences to a line of code that should, in any case, always be set. I call the whole matter silly. In any case, I would issue a warning at the administrator if he chose a custom theme and leaves the mobile theme empty. Admin, ye be warned!
I think that the default theme should go over the "mobile" one, because the potential damage of leaving "loose" DOM objets or miss some javascript code is worse than layout problems.
@x00 said:
Plugins have to be marked as mobile friendly.
But that setting only is only accounted for by the theme itself. That is, the framework doesn't automatically remove unfriendly plugins, the theme has to do it.
@JohanRonstrom said:
This is exactly my point. If I have not chosen a mobile theme, I do not want Vanilla to >choose one for me.
If this is a deliberate choice that feels logical to you, feel free to keep it as is. I was merely >venting a suggestion based on my experience as a sysadmin with other php systems, that >this feels like yet another of those coders' choices in a world where more laymen than >coders uses web systems.
I have no need to discuss this further, no big deal. I'm sorry if my post was confusing, >and that you felt the need to get so defensive about it.
Not defensive at all. I also wondered why there was no dashboard way to choose mobile themes, then peregrine made me a plugin that one could choose form the dashboard from a select group of css style sheets a person could pick to be the mobile.
Yes it was not perfect in that you needed to provide the style sheets to meet your specs but that is what being able to make a theme is all about. I have permission to distribute the plugin if you want , but that is as close to mobile theme choosing automation gets.
This means you still have to do something. Oh rats
I don't understand the discussion at all. Vanilla should have 1 theme which is fully responsive and that's it. Otherwise people will complain about wrong selected themes and you have to deal with fu**ing browser settings stuff like "hey I'm a desktop browser but in fact I'm a 100px display but I hide this information from you". Make a theme which fits nicely on every resolution and all problems are gone.
Why I think so? Made this experience when the website of my job launched with responsive+browser settings import. Just responsive would have been better in my oppinion, but I'm not a programmer there. Secondly I'm still developing my own private project page fully responsive without any dependencies from browser settings. Works like a charm on desktop, tablets and mobile phones (looks like an app there).
The beta should start in the next week or two. Delays on our side as usual. We just hired 4 developers in the past 4 months (doubling the Vanilla staff developer team) so the onboarding has been pretty extreme. But I'd say that bodes pretty well for the future, no?
I dunno, is that not what every else calls training for new employees? The gap between when they are hired and become fully useful is their "onboarding" phase.
@Linc said:
I dunno, is that not what every else calls training for new employees? The gap between when they are hired and become fully useful is their "onboarding" phase.
@Guido Richter: Responsive is not necessarily the way to go. If you have a large community, device relevant banner advertising and want OnPage SEO techniques on the different versions all the php splits you need to integrate are pain in the a** and gain momentum of rocket science. I set up almost all my bigger portals with 2 versions (desktop/tablet and smartphone) or more. In longterm and regarding accessibility of the code... > split it and do not go responsive.
VanillaAPP | iOS & Android App for Vanilla - White label app for Vanilla Forums OS
VanillaSkins | Plugins, Themes, Graphics and Custom Development for Vanilla
Comments
Thank you VERY MUCH. That helped. How is this pull request not merged yet?
It would still be great to have a date for the 2.2 official beta release...
I know, it was a feature request.
I seem to have stepped on a rather soar and grumpy toe, lol.
My only point was this:
It makes sense that the mobile theme is set to 'mobile' in the shipped config, witch it is. My issue is that if you remove the line, or leave the value blank, it does not make sense to me for the system to fallback to a value that I have never ever chosen (nor would ever choose). In my mind (and in all other systems I run, including i.e wordpress) removing the setting for mobile theme is the same as removing the use of a mobile theme (AKA not having a specific mobile theme, AKA fallback on the chosen main theme).
This is exactly my point. If I have not chosen a mobile theme, I do not want Vanilla to choose one for me.
If this is a deliberate choice that feels logical to you, feel free to keep it as is. I was merely venting a suggestion based on my experience as a sysadmin with other php systems, that this feels like yet another of those coders' choices in a world where more laymen than coders uses web systems.
I have no need to discuss this further, no big deal. I'm sorry if my post was confusing, and that you felt the need to get so defensive about it.
No discussion, just one explanation: if Vanilla reads from configuration it has a "sane" fallback - some value that made sense somewhere in the past. It must be "sane" in that it has a valid value - something that is not causing errors. So when there is no mobile theme given, it falls back to a working mobile theme. That's the logic behind it.
Vanilla simply doesn't assume that your main theme is mobile ready. If it will ever be the case that every theme is mobile ready, it would make sense to change that default, but until then, the fallback must be safe.
I'd argue that a default "mobile" theme is not saner than your own theme. I mean, imagine you have your own plugins and stuff that need to be properly dealt with by the theme. Is it better to load the default mobile and leave all that undealt with? I think that the default theme should go over the "mobile" one, because the potential damage of leaving "loose" DOM objets or miss some javascript code is worse than layout problems.
That being said, we are arguing over minor differences to a line of code that should, in any case, always be set. I call the whole matter silly. In any case, I would issue a warning at the administrator if he chose a custom theme and leaves the mobile theme empty. Admin, ye be warned!
Plugins have to be marked as mobile friendly.
grep is your friend.
But that setting only is only accounted for by the theme itself. That is, the framework doesn't automatically remove unfriendly plugins, the theme has to do it.
https://github.com/vanilla/vanilla/blob/054707aef5ec71507935fa71760ee394eaa45c5e/themes/mobile/class.mobilethemehooks.php#L19-L25
Search first
Check out the Documentation! We are always looking for new content and pull requests.
Click on insightful, awesome, and funny reactions to thank community volunteers for their valuable posts.
Sure but that is the default mobile theme, and boilerplate for traditional mobile themes.
grep is your friend.
Not defensive at all. I also wondered why there was no dashboard way to choose mobile themes, then peregrine made me a plugin that one could choose form the dashboard from a select group of css style sheets a person could pick to be the mobile.
Yes it was not perfect in that you needed to provide the style sheets to meet your specs but that is what being able to make a theme is all about. I have permission to distribute the plugin if you want , but that is as close to mobile theme choosing automation gets.
This means you still have to do something. Oh rats
❌ ✊ ♥. ¸. ••. ¸♥¸. ••. ¸♥ ✊ ❌
@vrijvlinder choosing a mobile theme from the dashboard will be possible in 2.2
You only need to add
'IsMobile' => trueto the ThemeInfo arrayMy themes: pure | minusbaseline - My plugins: CSSedit | HTMLedit | InfiniteScroll | BirthdayModule | [all] - PM me about customizations
VanillaSkins.com - Plugins, Themes and Graphics for Vanillaforums OS
I don't understand the discussion at all. Vanilla should have 1 theme which is fully responsive and that's it. Otherwise people will complain about wrong selected themes and you have to deal with fu**ing browser settings stuff like "hey I'm a desktop browser but in fact I'm a 100px display but I hide this information from you". Make a theme which fits nicely on every resolution and all problems are gone.
Why I think so? Made this experience when the website of my job launched with responsive+browser settings import. Just responsive would have been better in my oppinion, but I'm not a programmer there. Secondly I'm still developing my own private project page fully responsive without any dependencies from browser settings. Works like a charm on desktop, tablets and mobile phones (looks like an app there).
More reasons for 2.2 to be out already! When is 2.2 gonna be out?
The beta should start in the next week or two. Delays on our side as usual. We just hired 4 developers in the past 4 months (doubling the Vanilla staff developer team) so the onboarding has been pretty extreme. But I'd say that bodes pretty well for the future, no?
onboarding?
grep is your friend.
I dunno, is that not what every else calls training for new employees? The gap between when they are hired and become fully useful is their "onboarding" phase.
Ok it is American English according to Collins. Never heard of it.
We call this 'induction', and sometimes probation training if it a requirement for continuing to full employment.
grep is your friend.
http://en.wikipedia.org/wiki/Onboarding
Yep, onboarding is the right word, according to wikipedia, which we all know is gospel truth. ^^
I'd say that remains to be seen
PS: Congratulations for your expansion.
@Guido Richter: Responsive is not necessarily the way to go. If you have a large community, device relevant banner advertising and want OnPage SEO techniques on the different versions all the php splits you need to integrate are pain in the a** and gain momentum of rocket science. I set up almost all my bigger portals with 2 versions (desktop/tablet and smartphone) or more. In longterm and regarding accessibility of the code... > split it and do not go responsive.
Trust the yanks to come up with a buzz word for "training"
Induction training or gtfo. 
grep is your friend.
AKA "One of us... one of us..."
Canadians actually use onboarding too