Squid

templateURL more trouble than its worth?

6 posts in this topic Last Reply

Recommended Posts

@Djoss @CHBMB @aptalca @saarg @sparklyballs @binhex @otherPeople that I can't be bothered to figure out who to point to this thread.

 

Is the templateURL entry in a template basically proven to be more trouble than its worth considering how users are utilizing their containers nowadays?  Is the support requests coming from dockerMan automatically updating the user templates based upon what the maintainer's latest version of the template a pain in the ass?  Or should this tag (and the ability for dockerMan to continue to update the template) remain? 

Share this post


Link to post
Posted (edited)

Alternatively, would simply getting rid of the updates to the webUI solve most of your problems?

 

The current list of updated elements are 'Support', 'Overview', 'Category', 'WebUI', 'Icon', and any Config tag

Edited by Squid

Share this post


Link to post
16 hours ago, Squid said:

Is the support requests coming from dockerMan automatically updating the user templates based upon what the maintainer's latest version of the template a pain in the ass?

 

for me, i get very little support issues caused by this, now that could be because people haven't enabled this feature (cos they are running an old template and haven't run FCP to enable it) or because the feature just seems to work, i couldn't say, but i like the idea of it, as templates can change and having the ability to push out changes to users is a good idea IMHO.

 

i guess another question is squid, how much of a pain in the ass is it for you? :-).

 

 

Share this post


Link to post

It's a good idea and other than the webui parameter I like it.

Sent from my LG-H815 using Tapatalk

Share this post


Link to post

Next release, webUI updating is removed and replaced with Project instead

Share this post


Link to post

I also never got issues with that.  It's a good way to fix templates or add new stuff to it.  In fact it's a good way to reduce support requests.

 

The only potential issue I see is that it's not possible for a user to remove an optional config element, since it will come back with the next update.  So maybe it could be useful that have a way to indicate that a config element in the template is present but disabled (ignored, not used).

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


Copyright © 2005-2018 Lime Technology, Inc.
unRAID® is a registered trademark of Lime Technology, Inc.