About encouraging novices to set permission to this level, well, if vanilla creates a mechanism for a fast and automatic plugin installation, novices won't be needing to do this. I think the community should gather and decide to develop this feature. I'm also available to contribute in this.
This sentence shows you don't understand what I mean.
Novices do need to learn how to do it. That is the point. Running a site has a learning curve, and people's impatience is why they have poor security.
A web application/script managing file system is the tail wagging the dog. a cgi script should have that level of access in the first place not access over http. If it was over ssh that is a different matter. There is a wordpress plugin which combines http interface, with ssh updates, and replaces the standard updater.
Modern framework management doen't work on this basis, they work on the basis of deployment, through tools like fabric.
Wordress updater was very controversial feature even amongst their core team. Wordress is one of the most targeted frameworks.
@x00 there are plenty ways of doing that. Either one have their pros and cons. I understand that a cgi script should handle the file management on the lower level, and the http should be the interface on the higher level.
But even doing the command lines scripts would be very dangerous. As every approach you need to maintain security. I understand that perfeclty.
On the ssh approach, you could find servers that wouldn't allow that, or that you need to configure the server to allow that. And the main objective is to allow anyone to quickly install the forum (even if they don't know how to configure a server).
But I don't want to discuss that. What I've made was a simple and quick way to automatize the process. Just that! Instead a user doing that manually, a script will do the same steps as that.
For a vanilla distribution, I agree 100% with you, that it should have a more robust way to handle that. But here, it's not the case, it's meant to be simple.
So please, let's not discuss technologies approaches on this discussion, because we would do anything else rather than that. Hehe.
You are basically making a vanilla installer, that fact that it installs a theme too is secondary. You are saying to put it in the web folder. Which mean that web folder needs to be writeable by the web user.
if there is any vulnerability the whole of the web folder could be vulnerable to writes.
I'm not trying to nitpick, just explaining the limitations.
You are managing the installation of vanilla but you don't know much about the end user's server. Whether you install automatically or not if there is a problem with the vanilla installation it is still goign to fail.
This doesn't save all that much time, for less good security.
One click installer on popular panel already know a bit about he server becuase server deployments come packaged with the panel (Although I'm not a fan of these installers).
@creativedreams said:
Simeon_Griggs Offcourse there is a mobile version.
Just resize your browser and you will quickly see the responsiveness of the forum.
If you want, you can also see it on a mobile.
Cheers
I did load it on a mobile, it loaded the default mobile theme. Think you need to check your demo site.
In order to set any theme as the mobile theme, you have to change/add $Configuration['Garden']['MobileTheme'] = 'ThemeName'; to your /conf/config.php
Well, that said, you could try adding $Configuration['Garden']['MobileTheme'] = $Configuration['Garden']['Theme']; to the end of your /conf/config.php in order to always use the same theme on mobile as on desktop...
@Simeon_Griggs R_J have give you the solution to that. @R_J thanks for helping Simeon. I already put that on the theme hooks, so when you activate the theme it will make that configuration automatically. This will be ready on the new version of the theme, coming out very soon.
You who have bought the theme will receive a warning email.
Cheers
@creativedreams said:
R_J thanks for helping Simeon. I already put that on the theme hooks, so when you activate the theme it will make that configuration automatically.
... which I think is bad. Being able to use 2 different themes is a feature. You should better make this an optional setting.
By the way: on my mobile I still see the panel next to the discussions which is not very mobile friendly. So as long as that isn't changed, I wouldn't recommend to use your theme for mobile devices.
@R_J it's not bad using by default the same theme as the original. VAnilla allows to use 2 different themes for desktop and mobile, which is a great feature if a theme doesn't allow mobile. But since OneClick is responsive, better yet, is liquid, it's support mobile. So by default I really think it should have OneClick theme also.
About you seeing the panel, well it all depends on the mobile. For other mobiles, the panel will stay bellow and the UI is more mobile friendly.
I think you should focus on the theme and not worry about installing vanilla. The whole "one click" thing is not really worth it. Your real asset is your theme. The amount of time "one click" saves is minimal, it is the difference between uploading vanilla+theme and uploading your installer basically.
Or at the very least say if they wanted to demo vanilla, they could do an one click install in a sub directory.
If you were developing a deployment pattern for vanilla projects that is different matter. Or if you were offering a hosted solution.
@creativedreams said:
R_J it's not bad using by default the same theme as the original.
If I change my desktop theme, I do not expect that my mobile theme is changed as well, because that's against Vanillas common practices. That's why I consider it bad.
You can use base_render_before() to temporarily set config settings using saveToConfig('Garden.Profile.MaxHeight', 300, false); - the final false makes it temporary only for that pageload (in memory) and doesn't write to the actual config.php file. This also means you can skip the onDisable() routine, and it will gracefully go back to whatever the person was using before enabling the theme.
I second @R_J's advice to try to minimize how many individual views you override. In our experience, this causes long-term brittleness in how well a theme holds up over the course of years and unexpected plugin combos. I'd be concerned about this increasing support costs.
Comments
This sentence shows you don't understand what I mean.
Novices do need to learn how to do it. That is the point. Running a site has a learning curve, and people's impatience is why they have poor security.
A web application/script managing file system is the tail wagging the dog. a cgi script should have that level of access in the first place not access over http. If it was over ssh that is a different matter. There is a wordpress plugin which combines http interface, with ssh updates, and replaces the standard updater.
Modern framework management doen't work on this basis, they work on the basis of deployment, through tools like fabric.
Wordress updater was very controversial feature even amongst their core team. Wordress is one of the most targeted frameworks.
grep is your friend.
Alternatively a command line script they can run on the server, which means you don't need ssh, etc. php can be made comandline only.
A client side script could use ssh or ftp fallback, which means they don't even need to upload the installer.
grep is your friend.
@x00 there are plenty ways of doing that. Either one have their pros and cons. I understand that a cgi script should handle the file management on the lower level, and the http should be the interface on the higher level.
But even doing the command lines scripts would be very dangerous. As every approach you need to maintain security. I understand that perfeclty.
On the ssh approach, you could find servers that wouldn't allow that, or that you need to configure the server to allow that. And the main objective is to allow anyone to quickly install the forum (even if they don't know how to configure a server).
But I don't want to discuss that. What I've made was a simple and quick way to automatize the process. Just that! Instead a user doing that manually, a script will do the same steps as that.
For a vanilla distribution, I agree 100% with you, that it should have a more robust way to handle that. But here, it's not the case, it's meant to be simple.
So please, let's not discuss technologies approaches on this discussion, because we would do anything else rather than that. Hehe.
You are basically making a vanilla installer, that fact that it installs a theme too is secondary. You are saying to put it in the web folder. Which mean that web folder needs to be writeable by the web user.
if there is any vulnerability the whole of the web folder could be vulnerable to writes.
This needs a rethink.
grep is your friend.
I'm not trying to nitpick, just explaining the limitations.
You are managing the installation of vanilla but you don't know much about the end user's server. Whether you install automatically or not if there is a problem with the vanilla installation it is still goign to fail.
This doesn't save all that much time, for less good security.
One click installer on popular panel already know a bit about he server becuase server deployments come packaged with the panel (Although I'm not a fan of these installers).
grep is your friend.
I did load it on a mobile, it loaded the default mobile theme. Think you need to check your demo site.
In order to set any theme as the mobile theme, you have to change/add
$Configuration['Garden']['MobileTheme'] = 'ThemeName';to your /conf/config.phpWell, that said, you could try adding
$Configuration['Garden']['MobileTheme'] = $Configuration['Garden']['Theme'];to the end of your /conf/config.php in order to always use the same theme on mobile as on desktop...@Simeon_Griggs R_J have give you the solution to that.
@R_J thanks for helping Simeon. I already put that on the theme hooks, so when you activate the theme it will make that configuration automatically. This will be ready on the new version of the theme, coming out very soon.
You who have bought the theme will receive a warning email.
Cheers
@R_J congig.php is often overwritten, so setting dynamic setting is futile.
grep is your friend.
... which I think is bad. Being able to use 2 different themes is a feature. You should better make this an optional setting.
By the way: on my mobile I still see the panel next to the discussions which is not very mobile friendly. So as long as that isn't changed, I wouldn't recommend to use your theme for mobile devices.
different when i login in your support forum
thanks for answer @creativedreams
@R_J it's not bad using by default the same theme as the original. VAnilla allows to use 2 different themes for desktop and mobile, which is a great feature if a theme doesn't allow mobile. But since OneClick is responsive, better yet, is liquid, it's support mobile. So by default I really think it should have OneClick theme also.
About you seeing the panel, well it all depends on the mobile. For other mobiles, the panel will stay bellow and the UI is more mobile friendly.
@jobbatam, all the support for this product will be made through:
http://www.one-click-forum.com/support/forum/
Go there and you will have all the help that you need.
I think you should focus on the theme and not worry about installing vanilla. The whole "one click" thing is not really worth it. Your real asset is your theme. The amount of time "one click" saves is minimal, it is the difference between uploading vanilla+theme and uploading your installer basically.
Or at the very least say if they wanted to demo vanilla, they could do an one click install in a sub directory.
If you were developing a deployment pattern for vanilla projects that is different matter. Or if you were offering a hosted solution.
grep is your friend.
If I change my desktop theme, I do not expect that my mobile theme is changed as well, because that's against Vanillas common practices. That's why I consider it bad.
Hi, it's with great joy that I announce that OneClick theme now supports Vanilla 2.2 and YAGA.
http://www.one-click-forum.com/theme-preview/14_yaga_discussion.jpg
http://www.one-click-forum.com/theme-preview/15_yaga_best.jpg
http://www.one-click-forum.com/theme-preview/16_yaga_profile.jpg
http://www.one-click-forum.com/theme-preview/17_yaga_badge.jpg
Hope you guys like it.
Cheers
Looks really good, keep up the great work (like seriously)!
You can use
base_render_before()to temporarily set config settings usingsaveToConfig('Garden.Profile.MaxHeight', 300, false);- the finalfalsemakes it temporary only for that pageload (in memory) and doesn't write to the actualconfig.phpfile. This also means you can skip theonDisable()routine, and it will gracefully go back to whatever the person was using before enabling the theme.I second @R_J's advice to try to minimize how many individual views you override. In our experience, this causes long-term brittleness in how well a theme holds up over the course of years and unexpected plugin combos. I'd be concerned about this increasing support costs.
Thanks for the tip.
What's the latest theme version? Where can I download it? Site says item no longer available