Previous 1 2 Next 18 Replies Latest reply: Mar 11, 2008 5:08 AM by Erik Ableson Go to original post
  • Bryson Gore Level 1 (0 points)
    w.r.t the custom sidebar 'breaking' the page see

    Apple know about this.
  • Thyb Level 1 (5 points)
    I was exactly on the same boat as you I think.
    I created my theme as described previously.
    I wanted to modify an existing one so I had to copy the dependant themes as well into my new theme folder.

    Before adding the xsl files I wanted at least to test the css part of it. Say changing the default banner and few colors.

    But the new theme wasn't displayed on the list of selectable themes.

    After few restart of the teamserver through Terminal, then the web service through SA, then the whole server, duplicating the theme etc. suddenly the new theme appeared on the list.
    I've selected it and boum the red become blue.

    So I started to copy the xsl files as I wanted a specific default.xsl and changed all the necessay links described previously.
    Then without modifing anything restarted teamserver. And everything still worked fine.

    I thought everything is OK now for me to mess it up.

    I've just added added at the end of the default.xsl, before the </body> the following lines:
    <xsl:copy-of select="context"/>
    It's supposed to give a dump of each context at the end of your pages. Very useful for debugging.

    But then bam! After the restart the new theme disapeared from the list and my wiki just displayed a default theme (green).

    Here what /Library/Logs/wikid/error.log displays :

    [HTTPChannel,0,] Bad theme name requested
    [HTTPChannel,0,] '*** Default theme is invalid, falling back to first found theme ***'

    Bad name?
    How is it possible when the new theme is selected and is displayed in:
    Server Admin/Web/Settings/Web Services/Default Wiki and Blog Theme

    Is there anything to do with a cache?
    So instead of restarting teamserver through Terminal I always restarted the whole Web services through Server Admin as I read somewhere that it clean the Apache cache amongst other things.

    I scratched my head and then I looked a the directories using Path Finder:
    I saw plenty of invisible files starting with a dot and an underscore '._'.
    Using Terminal you can only see those files by being root or using the command "ls -a"

    I don't know what create those files but as soon as you delete them everything works fine (as far as your theme is not buggy of course

    If there is "._theme.plist" the new theme do not appear on the list.
    If there is a "._default.xsl" the new theme do not load. (Bad name error)

    Update: I was using TextMate to modify my files. And it seems to be the beast creating those files with special instructions for TextMate only. Somehow teamserver didn't liked them.
    TextMate was cool because you could open the whole directory and navigate through the files very easily. Plus it displays the files with syntax in color. So when you learning xsl that's handy.
    But be aware of this "bug".

    That's my findings so far. They might help someone.
  • Thyb Level 1 (5 points)
    Update about those ._ invisible files, from the Textmate doc:

    *Extended Attributes (Metadata)*

    Starting with Tiger, OS X supports setxattr and friends.

    TextMate makes use of extended attributes to store the carets position, bookmarks, what text is >folded and is likely to make further use of extended attributes in the future.

    For filesystems which do not natively support extended attributes (like network mounted disks), OS X >instead stores the extra information in a file named ._«filename», where «filename» is the name of the >original file.

    Since not all users think that this extra (hidden) file is worth having in order for TextMate to >remember state, it is possible to disable the use of extended attributes by quitting TextMate and >running the following from the shell:
    defaults write com.macromates.textmate OakDocumentDisableFSMetaData 1

    I was accessing the /Library/Application Support/Apple/WikiServer/Themes/ through a mounted volume.

    Well, we learn everyday..
  • Erik Ableson Level 1 (85 points)
    Maximilian Reiss wrote:
    And make sure to not forget the %20 as substitute for the space in "Application Support".

    e.g.: "/Library/Application%20Support/Apple/WikiServer/Themes/newtheme.wikitheme/defa ult.xsl"

    Hmmm - I've been fiddling with this off and on for a while now, and have followed the instructions noted. I do want to modify the default.xsl behaviour however, and when I update all of the files to point to my theme specific default.xsl file, lots of stuff breaks.

    Notably, it would appear that there are a number of relative paths in some of the other xsl files, and now I have a pile of html code that's being rendered on the main page. The first and most obvious broken link is the "Updated by" info which spits out:

    Updated Mar 4, 2008 10:10 AM by a href="/groups/testgroup/search/?q=none&fields=lastModifiedAuthor" none /a …" ( stripped out to prevent rendering of the link in this message)

    I've gone through all of the local files and lastModifiedAuthor only shows up in search.xsl with the following line:

    <option value="lastModifiedAuthor"><xsl:value-of select="../jsstrings/searchsortauthor"/></option>

    which leads me to believe that the ../ is broken now that I'm not pointing to the apple_template themes. That said, I'm not sure how to fix it since I can't find any reference to "jsstrings" anywhere.

    Message was edited by: Erik Ableson - fixed embedded html
Previous 1 2 Next