solved After skin or module updates by the original developer, what happens to customizations?

I am now talking to a "CSS guy" who can make CSS changes to my skin, in order change the appearance and organisation of my JR site. Things like the colour of the menu background, the layout of profile pages, or the automatic capitalisation of headings.

Do all CSS changes have to be redone manually every time the skin is updated by the original skin developer?

My hope is to make changes that do not affect basic operations or structure of the skin. What dangers should I be aware of? Here are two related questions:

(1) What kinds of CSS customizations will be wiped out by any skin update?
(2) What kinds of skin update will wipe out all CSS customizations?

I have the same problem with regard to customizations and module updates:

(3) What kinds of CSS customizations will be wiped out by any module update?
(4) What kinds of module update will wipe out all CSS customizations?

I expect there are answers to these questions here and there in the documentation, but a summary of how to approach this, as a non-coder seeking help with coding, would be very helpful.

Thanks


--
PJ Matthews, Kyoto
Migrated from Ning 2.0. Now at Jamroom 6 beta and using Jamroom Hosting for The Research Cooperative (researchcooperative.org)
updated by @researchcooperative: 04/16/16 08:55:54PM

The best way to do this would be to clone the skin you want to customize.

https://www.jamroom.net/the-jamroom-network/documentation/skins/839/creating-your-own-skin

This way, updates won't interfere with your custom skin.


--

Douglas Hackney
Jamroom Team - Designer/Developer/Support
FAQ-Docs-Help Videos

Thanks... that makes sense, but then how do I gain the benefits of updates? I want the best of both worlds... a regularly updated skin, and customization.

I am sure there are settings or other changes that do not interfere with a skin or module itself, but I do not know exactly what they are. From experience I see that quota allocations and settings made in the ACP remain fixed through multiple module updates.

I do not know the significance of the template (.tpl) files here. Are they always stable despite skin and module updates?

Do they affect skin appearance or module function or both? Do some templates affect module function and others skin function?

If I ask someone to change styling of my website (appearance and layout) can everything be done through templates in a way that allows changes to persist after updates to the skin and modules?

What kinds of change can be made by either direct CSS editing or by template, and which method is better to use?


--
PJ Matthews, Kyoto
Migrated from Ning 2.0. Now at Jamroom 6 beta and using Jamroom Hosting for The Research Cooperative (researchcooperative.org)
updated by @researchcooperative: 01/08/16 04:49:01PM

Just wondering if you saw my response on how you can easily change your capitalization settings, via your ACP-> Style (css files) TAB: https://www.jamroom.net/the-jamroom-network/forum/new_posts/36881/do-private-notes-have-an-outbox#last

Changing colors and font styles and spacing issues can all be changed the same way. It took me a little trial and error (and taking down notes when i hit on the right location in the Stle CSS settings for each item, so I wouldn't forget). After a while I began to get a sense of where to find some of these settings in the Style Css TAB and the .css files.

You'll want your own custom SKIN that you keep backed up. That will normally be your site's ACTIVE skin. You start with a pristine Jamroom skin (like Elastic or Ningja) and make a CLONE of it and name it with your custom skin name. When you style your site, you make your custom changes to your custom skin, not to the parent JR skin. It's the parent JR skin that will get the updates from JR periodically. After each update, you can use the skin COMPARE tool to compare the prior JR skin template in question to the new updated JR skin template, to see exactly what the change was and the code will show as newly added. Then you can decide whether you want that new updated change added to your CUSTOM skin...and you add it or not, yourself. Sometimes the change is only a little snippet in the code. If it's hard to find you can ask the JR Team where the new code update is located- in WHICH template in the updated JR skin. Knowing which template has been updated is very helpful when using the Compare tool.

In short, keep an original non-customized JR 'parent' skin and the skin updates from Jamroom will update THAT one. Also create your own custom skin as a clone of the parent skin- your ACTIVE custom skin will have your own skin name and you'll be backing it up periodically for safekeeping. When JR releases updates to the JR skin, you look to see if it's an update that you want to apply to your custom skin- then you locate the new code changes and apply them to your custom skin. (make a backup of your custom skin always before making any changes, in case things get screwed up!)
By the way, this is a handy backup module to have and USE: https://www.jamroom.net/the-jamroom-network/networkmarket/22/db-and-system-backup
But also learn how to use the ACP-> Developer's Tools-> "Clone Skin" function so you can back up your custom skin to keep it safe, as a habit, before making changes and possibly messing things up.

Learn how to use the "Compare" feature in ACP skin and module templates- at first just look at the differences in the old and new versions of module templates. Being able to do this will be incredibly useful going forward, even if you don't learn how to write code. You don't always need to understand code to see where a word or number has changed, and you can then change a menu link wording or add a row to some picture grid yourself, for example.
Hope some of this helps




--
...just another satisfied Jamroom customer.
Migrated from Ning to Jamroom June 2015
updated by @strumelia: 01/08/16 04:55:23PM

Thanks very much. Your notes on the headings and capitalisation control are great.

I will ask the CSS guy to follow this thread too, as he is not yet familiar with JR.

Will now look at the backup module.

Cheers


--
PJ Matthews, Kyoto
Migrated from Ning 2.0. Now at Jamroom 6 beta and using Jamroom Hosting for The Research Cooperative (researchcooperative.org)

If you learn a little every week, one morning you'll wake up and amaze yourself that you can make some changes to your site yourself!

Just follow careful safety procedures, because you 'will' make some mistakes along the way. Back everything up! - especially before making any changes or testing.


--
...just another satisfied Jamroom customer.
Migrated from Ning to Jamroom June 2015

@michael

At the start of this thread, I asked what happens to customizations after updates to skins and modules.

Another way to ask this question is to ask what kinds of customizations affect just the skin, what kinds affect just a module, and what kinds affect both?

Coming to this from the outside of the outside, I really do not know the answers. I don't even know how to ask the question properly. I have no overview or previous experience that can tell me.

From the answers so far, above, I gather that updates to a skin can wipe out customizations, but I don't know if this applies to all customizations.

For example, if we design a new profile form with form designer, does that represent a change to a skin, or is it something that new skin updates will recognise and keep?

If we design a new profile form with form designer, but then do some coding so that it only applies to a particular quota, and not all quotas, does that represent a change to a skin, a module, or both, or neither? And if it does change either or both, will it get wiped when there are updates?

Do we have to clone all modules as well skins, to be safe, and then manually transfer code changes in updated skins and modules using comparison tools? Does this mean that the costs of maintaining a JR site will gradually increase as we customise further and further?

I need some kind of overview so that I can know whether my requests to a developer or CSS code guy are possible and reasonable, or possible but problematic, or just not possible.

I might ask for something that seems simple to me, but which is technically difficult or leads to greater problems.

The person employed might also not have oversight on the matter, as he has not worked with Jamroom before (not many developers/coders have).


--
PJ Matthews, Kyoto
Migrated from Ning 2.0. Now at Jamroom 6 beta and using Jamroom Hosting for The Research Cooperative (researchcooperative.org)
updated by @researchcooperative: 01/14/16 05:50:14AM

Modules will take care of their own templates, unless you override them. skins can over-ride a modules template.

Docs: "Altering a Modules Template"
https://www.jamroom.net/the-jamroom-network/documentation/development/1051/altering-a-modules-template

So if the skin has NOT altered a modules template, AND the admin user has not altered the modules template, then an update to the module will be there for the skin in its default form to use.

However, since a skin can alter a modules template, and the admin user can alter the modules template via the template editor in the ACP, whatever either of those users chose to change it to, will remain the version in use until they are either reverted to the default or further desired changes are applied.

As for skin, if you clone the skin to a new name, its a new skin so no further changes made to the original skin will effect the cloned skin.

If you use the template editor to make changes to templates in an existing skin, then those overridden templates will stay in use even if there are changes made to the underlying template.

When the skin is updated the updates will be brought into the system, just not used. You can revert to using the original by clicking the RESET button on the particular template you're interested in, see:

Docs: "Using the Template Editor"
https://www.jamroom.net/the-jamroom-network/documentation/development/3183/using-the-template-editor

The other thing that might be desired is to bring the new changes into the overridden template and how you do this depends on where you made the changes in the first place.

If you did it in the file system via the skins files then you're probably a developer and so standard development systems take care of this for you, like using GIT to compare the existing skin with the newly changed skin to see what changed then apply the changes.

If you're doing it via the ACP then you can use the COMPARE button to compare any versions to see what changed and move those changes in line by line as desired.

Because there are many ways to do anything it sometimes becomes hard to answer broad questions as there are many unknowns.

Thanks - this makes some sense to me, and should make even more sense to CSS competent readers.

What I gather is that the templates system for both the skin and the modules is a way of making changes that will persist despite updates. Generally speaking.

That is, the custom templates in use will remain the templates in use unless one reverts to the defaults, which will be whatever is current in the latest update of a skin or module (if we always update when new updates appear).

If an update concerns an area of code that the custom template has replaced, then it may be desirable to update the custom template, using the methods you describe.

This now seems a little less scary than I was imagining. Please correct me if I have misunderstood the reply.

I'll look at the links you have given.


--
PJ Matthews, Kyoto
Migrated from Ning 2.0. Now at Jamroom 6 beta and using Jamroom Hosting for The Research Cooperative (researchcooperative.org)

'yes' to all above questions. Good comprehension. Nothing appears misunderstood.