[Building Sakai] Portal NEO Prefix

Matthew Jones matthew at longsight.com
Thu Mar 21 09:41:34 PDT 2013


I think what you're describing at the bottom here was the motivation for
the auto-append, trying to support both systems concurrently.

Say we have an existing school with 10 skins. When they upgrade to 2.9 they
either.

1) Leave all the skins as is, adjust a property and stay with the old
templates.
2) Update all of the skins to 2.9 style, append neo- to all of them (or
changed portal.neoprefix which is by default neo-) then switch to the new
templates.

Otherwise they'd have to run a DB conversion ONLY when they're ready to
make the switch and ONLY if they decide to put the templates into new
directories. If you have a skin called alphabet, you need to create a new
skin called alphabet. The place to put it (neo-alphabet) was just the
convention. Nobody provided that conversion script or any better process
around it. We didn't expect people to read the documentation (like most
probably didn't even for this change) even though I wrote it well over 6
months ago and just now it's coming up. (
https://confluence.sakaiproject.org/display/DOC/Sakai+CLE+2.9+portal+changes)
I'm personally happy with the properties and the process "as-is"

I also don't think it would be too difficult to have both old and new vm
templates be able to work in the same system, but I think
the consensus will be to delete the old templates in 2.10 anyway as they're
much better. If you don't want any prefix you probably can just set

portal.neoprefix=

And you then need to either in-place replace all of the skins or write a
conversion script for SAKAI_SITE, or else they would break custom skins as
you describe for any old ones that aren't updated. At least *with* a prefix
or with a skin column database conversion the break is obvious, which is
better and typically just a few minutes to get the css looking good.

The problem Dave Adams describes in the other thread was a problem before
this neo portal and *usualy* didn't come up because this default/tool.css
was just left as is and the same by convention for everyone.

On Thu, Mar 21, 2013 at 8:26 AM, Steve Swinsburg
<steve.swinsburg at gmail.com>wrote:
>
> As for SQL to adjust a skin set that a site has, unless the skin is
> incompatible with the templates in use then it's not needed. And a simple
> scan of the props table will tell you if someone is using a skin that is
> incompatible. It should all be taken care of at upgrade time.
>
> Again, there is *no* way for a skin that is currently in use to be
> automatically mapped to the neo equivalent. Work must be done to make a
> compatible version.
>
> Another real example:
>
> In 2.8 I have a site with a custom skin called alphabet. I upgraded to 2.9
> and the portal changed the name of that skin to neo-alphabet. This does
> *not* work. I don't have a skin called neo-alphabet. My site is broken,
> there is no CSS. So I need to actually do work to upgrade my skin/make a
> new one. But again I should be able to call my new skin whatever I want,
> and in this particular case I called my skin alphabet-v2.
>




>
> cheers,
> S
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20130321/ac157c68/attachment.html 


More information about the sakai-dev mailing list