Help - I just upgraded and lost my changes!

  • Your changes are not lost (if you used the Marketplace)

    First up the good news - your changes are not lost if you have used the Marketplace to upgrade your module or skin.

    The way the Marketplace works when you do an upgrade is it moves the new, upgraded version of the module or skin in as the "active" module or skin, and renames the old module or skin directory to a different name. This means your changes are never lost, they just aren't visible since the (modified) version of the module or skin is not active.

    If however you uploaded the new version of the skin or module via FTP and overwrote your existing files, then your changes would be lost (assuming you did not make a backup).
  • Recovering your changes

    To recover your changes or customizations, log into your Jamroom site using FTP and go to the modules (or skins) directory. For this example we will assume you made your customizations in the "Audio Support" module. The Audio Support module is located in the "jrAudio" directory (you can get the directory name for a module or skin from the "info" tab in the ACP).

    When logged in via FTP, I will see a directory structure that looks like this:

    jrAudio -> jrAudio-release-1.1.0
    jrAudio-release-1.1.0
    jrAudio-release-1.0.3
    

    Yours may look different depending on what you had upgraded or installed, but you should see at least 2 entries:

    - jrAudio - this is a symbolic link that simply "points" to the active jrAudio directory (in this case jrAudio-release-1.1.0). This will br active version of the jrAudio module.

    Underneath that you can see another directory - jrAudio-release-1.0.3. This is the next older version that was running on the site before it was upgraded to jrAudio-1.1.0. Inside this directory you will find your customized files!.
  • Never customize templates in the module or skin directories!

    It's important to know the proper method for customizing a Jamroom template!

    First - never log in via FTP and customize or change templates directly in a module's templates directory - i.e.

    modules/jrAudio/templates/item_detail.tpl

    DO NOT modify that file! The next time you upgrade, your changes will no longer be visible!

    The same goes for a Skin directory - i.e.

    skins/jrElastic/meta.tpl

    DO NOT change that file! The next time you upgrade the Elastic skin via the Marketplace your changes will no longer show.

    Like outlined above, your changes are not lost - they just are no longer active.
  • Step One: Clone the skin you want to customize

    The first step to customizing Jamroom correctly is to Clone the Skin you want to customize. So for our example we will clone the jrElastic skin:

    1) Download and install the Jamroom Developer Tools module from the Marketplace module inside your Jamroom, or download it here:

    https://www.jamroom.net/the-jamroom-network/networkmarket/50/developer-tools

    and upload it to your site using FTP.

    2) Once installed and activated, go to Developer Tools -> Tools -> Clone Skin and select the skin you want to customize. Give your skin a new, custom name and press the "Clone Skin" button.

    Now you have a COPY of the skin you want to customize that will never be changes during an upgrade.
  • Step Two: Override the default module templates

    So getting back to the template we want to customize, we are going to create a new file in the skin directory we just cloned.

    For this example let's pretend we named our cloned skin "Clone". When I log in via FTP and go to the skins directory, I will now see something like this:

    jrElastic
    Clone
    

    So "Clone" is now the active skin - it's a copy of the jrElastic skin, and is where I'm going to do my modifications.

    Earlier we want to customize the following template:

    modules/jrAudio/templates/item_detail.tpl

    so to do that, I'm going to create the following new file:

    skins/Clone/jrAudio_item_detail.tpl

    and customize it to suit my needs. When Jamroom "sees" there is a module override template located in the active skin directory, it will use that template in place of the default template that is provided by the module.

    So once we've done that, we are good to go:

    - our changes to the jrAudio item_detail.tpl cannot be made inactive by upgrading the Audio module
    - since we are making our changes to the "Clone" skin, it cannot be made inactive by upgrading the jrElastic skin.
MySong
30 Jun 2014 05:07:16AM @mysong:
1 question...

If the new upgraded version of the Audio module contained changes to item_detail.tpl (using the example given) and you had an override template located in the active skin directory for that file (skins/Clone/jrAudio_item_detail.tpl), how would you know that the changes of the upgrade were not registering and even if you did know, how would you now appy them. To clarify; this all works well if the upgrade did not update that file but if it did, then only a part of the upgrade gets installed.

MySong
30 Jun 2014 05:10:16AM @mysong:
Another question...

If instead of making changes to templates via FTP you make the changes via the 'Templates' tab in the ACP, what happens in this case? Will the changes get overwritten upon upgrade (know you can log in via FTP and recover them but asking if they will become inactive)?

brian
30 Jun 2014 11:24:22AM @brian:
This is what the "compare" tool is used for. Log in as a Master Admin and go to ACP -> Media -> Audio Support -> Templates. You can then use the "Compare" button to compare the current version of any of the module's templates to previous versions of the module's templates. That will let you see if anything has changed in the recent update and you can then copy those updates over to your custom template if you would like.

Hope this helps!

researchcooperative
07 Oct 2016 06:17:34AM @researchcooperative:
In the case of updates to an original JR Skin for which a clone has been created, how to we get to see JR updates in the cloned Skin?

Are there two kinds of compare tool?

1. For comparing original JR code and new custom code inside a cloned skin (or module)
2. For comparing new code in a JR skin or module with old (original) code in the clone, and the new custom code inside the clone.

Or more graphically (A-F = labels, not a sequence)

A) jrThing-old -> B) jrThing-new (updates made by JR)

C) jrThing-old -> D) jrThing-customnew (customizations by site owner, without using clone)

E) jrThing-old-Clone -> F) jrThing-old-Clone-customnew (customizations by site owner using clone)

Notes:
1. Comparing A) with B) is not possible within the updated Skin or module, but JR provides a separate chronological log of historical changes to everything JR has worked on.

2. Comparing C) with D) is easy to do (with the internal tools)

3. Comparing E) with F) is easy to do (with the internal tools)

4. The common question may be how to easily compare B) with D) or F), in order to make decisions? Is it possible to design an automatic alert system for non-coding administrators so we do not have to eyeball code endlessly? (Then ideally we can ask a technical assistant to monitor the alerts and deal with anything that needs dealing with).

My understanding is that D) gets wiped out and becomes B) if the updates made by JR are accepted.

Share This

Tags