Child pages
  • Administrative console skin upgrade
Skip to end of metadata
Go to start of metadata

Imported From:

Administrative console have "Admin Skins" section, that allows to change how administrative console will look (colors mostly). Administrator is able to change any skin any time. We, as developers, also change default skin used for new installations.

Problem happens on upgrade, since we don't know how to merge our skin file with one, administrator have changed. During upgrade to 5.1.0 version without that merge we won't be able to see new upload progress bars near each file.

Idea #1

To add CRC field to skin table and keep track what CRC default skin has in each In-Portal version. This way on upgrade we could check, that skin's crc from database differ from ones, used in In-Portal version before upgrade and warn administrator about that.

Administrator will then have 2 options: 

  • ignore his skin changes and overwrite it from default skin;
  • upgrade creates 2nd skin, named "Upgrade v X.Y.Z" and after upgrade administrator will manually compare changes.

Colors are pretty much standard and I'm more concerned about css template used.

Idea #2

To use patch like skin tracking system:

  • we create patch files on each skin change (e.g. "skin_patch_502_to_503.patch");
  • patch files will be pretty small, since we only have changed parts in them and we don't change skin much;
  • during the upgrade, when "patch" command is available (or maybe we can figure out php script that does that) we apply patches

When there is patching conflict, then administrator should resolve it manually after upgrade is finished. We could also create skin named "Upgrade v X.Y.Z" with all administrator and our changes to he can verify that it works without breaking it's current skin.

Post your thoughts about this here.

Related Tasks

INP-619 - Getting issue details... STATUS


  1. it's a good idea. In both cases, it'd be good that administrator is noticed
    of the skin change.

    Could we have a mix of #1 and #2:
       - original css isn't modified and a new css is created
       - may a script can look for modified lines and show it somewhere?

    It should be as easy as possible for administrator to track changes.

    2010/6/8 Alexander Obuhovich <>

  2. We could mix whatever we need to get proper result, that's why I need
    opinions on that.

    I doubt, that we will be creating something, like "Compare It!" program on
    php to just display skin changes. Also to display changed lines we need to
    keep all versions of all skins. That's why patch idea seems more
    appropriate, but it only will work on Linux.

    Also we could mix all skin patches from #2 idea into since file, like
    "upgrades.sql" where patches will be separated by In-Portal version numbers
    they belong to.

  3. I agree with your opinion, it could be too much complicated to "compare it",
    but I keep in mind that actual update are complicated by the fact we haven't
    anymore release notes (or I lost they path?), then we need to guess what is
    changed vs. unchanged things.

    If the patchning system works by itself, why not using it, it'd be an option
    for Unix-based installs only...

    2010/6/8 Alexander Obuhovich <>

  4. Sort of release notes is task list filtered by release. "Change Log Message"
    field in each task is like record in release note list.

    We are planning to pull them to somehow sometime.

  5. ok, I'll use it and post back here if I can't find info on all new
    functions in 510 :)

    2010/6/8 Alexander Obuhovich <>:

  6. I've implemented patch for this in

    INP-619 - Getting issue details... STATUS