Details

    • Type: Task Task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Fix Version/s: Initial Clearing
    • Component/s: CMS
    • Labels:
      None

      Description

      The logging PMC requests at test CMS instance named loggingtest
      together with a similarly named production site: Source URL is

      https://svn.apache.org/repos/asf/logging/site/branches/cms



        Activity

        Hide
        #asfinfra IRC Bot added a comment -
        <danielsh> It would make our lives much easier if we had to manage just one URL and one checkout. How feasible is that?
        Show
        #asfinfra IRC Bot added a comment - <danielsh> It would make our lives much easier if we had to manage just one URL and one checkout. How feasible is that?
        Hide
        Ralph Goers added a comment -
        I wouldn't have asked if this wasn't necessary.
        Show
        Ralph Goers added a comment - I wouldn't have asked if this wasn't necessary.
        Hide
        Ralph Goers added a comment -
        Let me rephrase my previous answer. The main site needs to be maintained independently of the subprojects. Each of the subprojects need to be maintained from each other. We are open to any mapping that allows these requirements to be met without, hopefully, having to expose something extra in the website url.
        Show
        Ralph Goers added a comment - Let me rephrase my previous answer. The main site needs to be maintained independently of the subprojects. Each of the subprojects need to be maintained from each other. We are open to any mapping that allows these requirements to be met without, hopefully, having to expose something extra in the website url.
        Hide
        #asfinfra IRC Bot added a comment -
        <danielsh> Just build the sites into a common hierarchy? We monitor just one URL, and each subproject generates into ${URL}/${name_of_subproject}. But infra isn't aware of the subprojects. Only caveats is that generating the toplevel site mustn't kill subproject sites -- compare CMS's extpaths.txt feature.
        Show
        #asfinfra IRC Bot added a comment - <danielsh> Just build the sites into a common hierarchy? We monitor just one URL, and each subproject generates into ${URL}/${name_of_subproject}. But infra isn't aware of the subprojects. Only caveats is that generating the toplevel site mustn't kill subproject sites -- compare CMS's extpaths.txt feature.
        Hide
        Ralph Goers added a comment -
        But then checking out the toplevel site also checks out all the subprojects, correct? We would like to avoid that. I could see a structure like:

        logging/site/main/live
        logging/site/sub/log4j/live
        logging/site/sub/log4j2/live
        etc.

        So you just have two to monitor, but then I would expect the main website would have to include "sub" in the url.
        Show
        Ralph Goers added a comment - But then checking out the toplevel site also checks out all the subprojects, correct? We would like to avoid that. I could see a structure like: logging/site/main/live logging/site/sub/log4j/live logging/site/sub/log4j2/live etc. So you just have two to monitor, but then I would expect the main website would have to include "sub" in the url.
        Hide
        #asfinfra IRC Bot added a comment -
        <danielsh> svn checkout --depth=immediates
        Show
        #asfinfra IRC Bot added a comment - <danielsh> svn checkout --depth=immediates
        Hide
        #asfinfra IRC Bot added a comment -
        <danielsh> ... can be used to avoid checking out all the child dirs. (Sorry, I forgot the forum)
        Show
        #asfinfra IRC Bot added a comment - <danielsh> ... can be used to avoid checking out all the child dirs. (Sorry, I forgot the forum)
        Hide
        Joe Schaefer added a comment -
        Why don't you just use the CMS and be happy? It supports exactly
        this kind of layout with extpaths.txt.
        Show
        Joe Schaefer added a comment - Why don't you just use the CMS and be happy? It supports exactly this kind of layout with extpaths.txt.
        Hide
        Ralph Goers added a comment -
        If we can use the CMS for the main site and svnpubsub for the subprojects that would be fine. Many of the subprojects are built with Maven but the actual project web site doesn't change that much and editing with a CMS would be fine. Where is extpaths.txt documented?
        Show
        Ralph Goers added a comment - If we can use the CMS for the main site and svnpubsub for the subprojects that would be fine. Many of the subprojects are built with Maven but the actual project web site doesn't change that much and editing with a CMS would be fine. Where is extpaths.txt documented?
        Hide
        #asfinfra IRC Bot added a comment -
        <danielsh> www.apache.org/dev/cmsref and search for extpaths.txxt
        Show
        #asfinfra IRC Bot added a comment - <danielsh> www.apache.org/dev/cmsref and search for extpaths.txxt
        Hide
        Joe Schaefer added a comment -
        Right Ralph- the way it'd work is you'd use the CMS for the main site and extpaths.txt + svnpubsub
        for the subsites. Each subsite could use svn externals to checkout their portion of the production
        site to their local build tree, rebuild and commit back.
        Show
        Joe Schaefer added a comment - Right Ralph- the way it'd work is you'd use the CMS for the main site and extpaths.txt + svnpubsub for the subsites. Each subsite could use svn externals to checkout their portion of the production site to their local build tree, rebuild and commit back.
        Hide
        Ralph Goers added a comment -
        So what needs to be done to make this happen?
        Show
        Ralph Goers added a comment - So what needs to be done to make this happen?
        Hide
        #asfinfra IRC Bot added a comment -
        <joes4> first you need to get the base site into cms form: see http://www.apache.org/dev/cmsadoption#maven for the details. Once that is done you'll create an extpaths.txt file to coordinate the copying of the existing subsites to the production treee.
        Show
        #asfinfra IRC Bot added a comment - <joes4> first you need to get the base site into cms form: see http://www.apache.org/dev/cmsadoption#maven for the details. Once that is done you'll create an extpaths.txt file to coordinate the copying of the existing subsites to the production treee.
        Hide
        Ralph Goers added a comment -
        Thanks for the link. The maventest site itself is built with Maven (which I'm not planning to do) and the site output appears to be destined for the target/site directory. It isn't at all clear how it ends up in the CMS svn directory. Under "for each component release" the doc says "import the generated site to https://svn.apache.org/repos/infra/websites/production/maventest/content/" which I took to mean it applies to each of the sub projects (the component release), not the main site, although that doesn't seem to make sense if externals are being used.

        I also looked at http://www.apache.org/dev/cmsref.html and checked out the template, but the skeleton stuff confused me if all I want to do is copy the existing HTML content - do I still need that? Since maventest doesn't have it I would think not? I also would like to test it out somehow before I commit anything to svn but stopped at "install python". I guess my Mac has both python and Perl installed but my my knowledge of Python is minimal and I've found that every time I go back to Perl I have to relearn it (I last used it about 7 years ago).
        Show
        Ralph Goers added a comment - Thanks for the link. The maventest site itself is built with Maven (which I'm not planning to do) and the site output appears to be destined for the target/site directory. It isn't at all clear how it ends up in the CMS svn directory. Under "for each component release" the doc says "import the generated site to https://svn.apache.org/repos/infra/websites/production/maventest/content/ " which I took to mean it applies to each of the sub projects (the component release), not the main site, although that doesn't seem to make sense if externals are being used. I also looked at http://www.apache.org/dev/cmsref.html and checked out the template, but the skeleton stuff confused me if all I want to do is copy the existing HTML content - do I still need that? Since maventest doesn't have it I would think not? I also would like to test it out somehow before I commit anything to svn but stopped at "install python". I guess my Mac has both python and Perl installed but my my knowledge of Python is minimal and I've found that every time I go back to Perl I have to relearn it (I last used it about 7 years ago).
        Hide
        Ralph Goers added a comment -
        Also, you mention "Each subsite could use svn externals to checkout their portion of the production site". I'm assuming that the external is in the tree of the main site and points to the location of the sub site so I would assume developers could directly check it out from there without needing to go through the external?
        Show
        Ralph Goers added a comment - Also, you mention "Each subsite could use svn externals to checkout their portion of the production site". I'm assuming that the external is in the tree of the main site and points to the location of the sub site so I would assume developers could directly check it out from there without needing to go through the external?
        Hide
        Ralph Goers added a comment -
        Sorry for all the comments. Re-reading the section on extpaths.txt under http://www.apache.org/dev/cmsref.html#generated-docs it seems that the idea is that when the site is updated files in those directories are simply not touched unless the directory is specifically published to. So no svn externals are on the production web site. In that case I'm not sure why svn externals would be used at all (the maventest site doesn't appear to have any).
        Show
        Ralph Goers added a comment - Sorry for all the comments. Re-reading the section on extpaths.txt under http://www.apache.org/dev/cmsref.html#generated-docs it seems that the idea is that when the site is updated files in those directories are simply not touched unless the directory is specifically published to. So no svn externals are on the production web site. In that case I'm not sure why svn externals would be used at all (the maventest site doesn't appear to have any).
        Hide
        #asfinfra IRC Bot added a comment -
        <danielsh> externals would be used on the subproject's site's source tree to pull the production/logging/content/$subproj URL.
        Show
        #asfinfra IRC Bot added a comment - <danielsh> externals would be used on the subproject's site's source tree to pull the production/logging/content/$subproj URL.
        Hide
        Christian Grobmeier added a comment -
        Before a while, one of us (Ivan) has created a new "main page" for logging. It is pretty cool and looks great.
        http://svn.apache.org/repos/asf/logging/site/branches/experimental-redesign/src/site/pages/

        Does the CMS support such kind of custom layouts? I could not find information on that matter. How difficult is creating a custom layout (for non perl speakers)?
        Show
        Christian Grobmeier added a comment - Before a while, one of us (Ivan) has created a new "main page" for logging. It is pretty cool and looks great. http://svn.apache.org/repos/asf/logging/site/branches/experimental-redesign/src/site/pages/ Does the CMS support such kind of custom layouts? I could not find information on that matter. How difficult is creating a custom layout (for non perl speakers)?
        Hide
        Christian Grobmeier added a comment -
        Here is a recent draft of the planned main site, just for your information: http://bezdomni.net/logging/
        Show
        Christian Grobmeier added a comment - Here is a recent draft of the planned main site, just for your information: http://bezdomni.net/logging/
        Hide
        #asfinfra IRC Bot added a comment -
        <danielsh> What needs to be done here?
        Show
        #asfinfra IRC Bot added a comment - <danielsh> What needs to be done here?
        Hide
        #asfinfra IRC Bot added a comment -
        <danielsh> ping: what needs to be done here? svnpubsub? cms? costume party?
        Show
        #asfinfra IRC Bot added a comment - <danielsh> ping: what needs to be done here? svnpubsub? cms? costume party?
        Hide
        #asfinfra IRC Bot added a comment -
        <danielsh> feedback timeout
        Show
        #asfinfra IRC Bot added a comment - <danielsh> feedback timeout
        Hide
        Ralph Goers added a comment -
        Sorry for the delay. We have been discussing how to build our site with Hervé and it has taken a bit of time.

        What we would like is to start with a "loggingtest" site similar to maventest so that we can get our site build working without disrupting the current site. What has been suggested is that the site be setup to use the CMS with the templating engine we are planning to use configured as an external task. The details of that are:

        generate the site using Twig [1], a nice PHP templating engine, in combination with Textile markup [2], which is much more versatile than most other common markup languages (such as markdown, apt, ...).

        The code for a sample logging site can be found here:
        http://svn.apache.org/repos/asf/logging/site/branches/experimental-twig-textile/

        The generated web site for demo is at: http://bezdomni.net/logging/

        The source code contains a file named README.md which has some details on getting twig to run.

        [1] http://twig.sensiolabs.org/
        [2] http://textile.sitemonks.com/
        Show
        Ralph Goers added a comment - Sorry for the delay. We have been discussing how to build our site with Hervé and it has taken a bit of time. What we would like is to start with a "loggingtest" site similar to maventest so that we can get our site build working without disrupting the current site. What has been suggested is that the site be setup to use the CMS with the templating engine we are planning to use configured as an external task. The details of that are: generate the site using Twig [1], a nice PHP templating engine, in combination with Textile markup [2], which is much more versatile than most other common markup languages (such as markdown, apt, ...). The code for a sample logging site can be found here: http://svn.apache.org/repos/asf/logging/site/branches/experimental-twig-textile/ The generated web site for demo is at: http://bezdomni.net/logging/ The source code contains a file named README.md which has some details on getting twig to run. [1] http://twig.sensiolabs.org/ [2] http://textile.sitemonks.com/
        Hide
        Ralph Goers added a comment -
        Also, our sub projects will use the extpaths.txt feature.
        Show
        Ralph Goers added a comment - Also, our sub projects will use the extpaths.txt feature.
        Hide
        #asfinfra IRC Bot added a comment -
        <danielsh> Can you provide a list of dependencies of your site's build process? (as port names -- see www.freshports.org -- for those deps that are in ports)
        Show
        #asfinfra IRC Bot added a comment - <danielsh> Can you provide a list of dependencies of your site's build process? (as port names -- see www.freshports.org -- for those deps that are in ports)
        Hide
        Ivan Habunek added a comment -
        Hi! I wrote the new build process for logging. Keep in mind that the current process is still experimental and can be modified to make it fit into your build process better.

        There are two dependancies: PHP runtime and the Twig library.

        For PHP, any of these should work fine:
        * http://www.freshports.org/lang/php5/ (5.4 branch)
        * http://www.freshports.org/lang/php53/ (5.3 branch)
        I would not recommend using the 5.2 branch, since it's no longer maintained.

        The Twig library is not in freshports, as far as I see. For testing I had it installed via PEAR. I think the easiest way would be to bundle the Twig package with the site code. It has an Apache-compatible licence so it shouldn't be a problem legally. Please say if this is OK with you.

        The build process is simple: execute "php build.php". This compiles the sources from /src and dumps the rendered site into /target/site.
        Show
        Ivan Habunek added a comment - Hi! I wrote the new build process for logging. Keep in mind that the current process is still experimental and can be modified to make it fit into your build process better. There are two dependancies: PHP runtime and the Twig library. For PHP, any of these should work fine: * http://www.freshports.org/lang/php5/ (5.4 branch) * http://www.freshports.org/lang/php53/ (5.3 branch) I would not recommend using the 5.2 branch, since it's no longer maintained. The Twig library is not in freshports, as far as I see. For testing I had it installed via PEAR. I think the easiest way would be to bundle the Twig package with the site code. It has an Apache-compatible licence so it shouldn't be a problem legally. Please say if this is OK with you. The build process is simple: execute "php build.php". This compiles the sources from /src and dumps the rendered site into /target/site.
        Hide
        Ivan Habunek added a comment -
        After confirming with danielsh on IRC, I have budled Twig into the experimetnal branch:
        http://svn.apache.org/repos/asf/logging/site/branches/experimental-twig-textile/
        (stripped tests and docs form the package to make it smaller)

        Now the only dependency is PHP runtime.
        Show
        Ivan Habunek added a comment - After confirming with danielsh on IRC, I have budled Twig into the experimetnal branch: http://svn.apache.org/repos/asf/logging/site/branches/experimental-twig-textile/ (stripped tests and docs form the package to make it smaller) Now the only dependency is PHP runtime.
        Hide
        Ralph Goers added a comment -
        I believe we are now waiting for Infra to create a test site.... ?
        Show
        Ralph Goers added a comment - I believe we are now waiting for Infra to create a test site.... ?
        Hide
        #asfinfra IRC Bot added a comment -
        <danielsh> What is the URL to an svn tree in CMS layout? (trunk/{content,lib,templates}) See http://www.apache.org/dev/cmsref#svn
        Show
        #asfinfra IRC Bot added a comment - <danielsh> What is the URL to an svn tree in CMS layout? (trunk/{content,lib,templates}) See http://www.apache.org/dev/cmsref#svn
        Hide
        Ralph Goers added a comment -
        <sigh> Now I'm confused again. Ivan's branch above isn't formatted the way the CMS template needs. The CMS also says it can use an external build tool which sounds like it would invoke php build.php as Ivan requires but I have no idea how to bridge the two. We could easily host the test site at https://svn.apache.org/repos/asf/logging/testsite/trunk if I knew how to do this.
        Show
        Ralph Goers added a comment - <sigh> Now I'm confused again. Ivan's branch above isn't formatted the way the CMS template needs. The CMS also says it can use an external build tool which sounds like it would invoke php build.php as Ivan requires but I have no idea how to bridge the two. We could easily host the test site at https://svn.apache.org/repos/asf/logging/testsite/trunk if I knew how to do this.
        Hide
        Hervé Boutemy added a comment -
        what's the problem? it's just a question of moving things in svn
        Do you want me to try?
        Show
        Hervé Boutemy added a comment - what's the problem? it's just a question of moving things in svn Do you want me to try?
        Hide
        #asfinfra IRC Bot added a comment -
        <danielsh> About invoking php(1) from CMS -- possible, see build_external.pl (linked from https://www.apache.org/dev/cmsref)
        Show
        #asfinfra IRC Bot added a comment - <danielsh> About invoking php(1) from CMS -- possible, see build_external.pl (linked from https://www.apache.org/dev/cmsref)
        Hide
        Ralph Goers added a comment -
        Herve - feel free to help.
        Show
        Ralph Goers added a comment - Herve - feel free to help.
        Hide
        Hervé Boutemy added a comment -
        ok, I don't have commit privs

        here is the first command necessary: have the site source in a trunk directory
        svnmucc -U http://svn.apache.org/repos/asf/logging/site/branches/ mkdir cms mv experimental-twig-textile cms/trunk -m "first requirement for CMS: be in a trunk base directory"

        then you'll need to move src/site/templates to templates and src/site to content and change the build.php script accordingly

        that should be near the end: there is still the output directory to define according to infra needs, ie take its value from site.output command line attribute
        Show
        Hervé Boutemy added a comment - ok, I don't have commit privs here is the first command necessary: have the site source in a trunk directory svnmucc -U http://svn.apache.org/repos/asf/logging/site/branches/ mkdir cms mv experimental-twig-textile cms/trunk -m "first requirement for CMS: be in a trunk base directory" then you'll need to move src/site/templates to templates and src/site to content and change the build.php script accordingly that should be near the end: there is still the output directory to define according to infra needs, ie take its value from site.output command line attribute
        Hide
        #asfinfra IRC Bot added a comment -
        <danielsh> s/http/https/
        Show
        #asfinfra IRC Bot added a comment - <danielsh> s/http/https/
        Hide
        Ralph Goers added a comment -
        OK - I populated https://svn.apache.org/repos/asf/logging/site/branches/cms/trunk/ and modified the build script to accept "-o targetdirectory".
        Show
        Ralph Goers added a comment - OK - I populated https://svn.apache.org/repos/asf/logging/site/branches/cms/trunk/ and modified the build script to accept "-o targetdirectory".
        Hide
        Ralph Goers added a comment -
        I didn't add the extpaths.txt yet - I am presuming I can add that after this is working?
        Show
        Ralph Goers added a comment - I didn't add the extpaths.txt yet - I am presuming I can add that after this is working?
        Hide
        Ralph Goers added a comment -
        Four items have been identified as being required to complete this.
        1) URL of site source (in CMS conforming layout ---
             Answer - https://svn.apache.org/repos/asf/logging/site/branches/cms/trunk
        2) where to send commit mails to
             Answer - commits@logging.apache.org
        3) a conforming build_cms.sh script (as called by build_external.pl it is passed a source directory and a target directory)

        4) we need to build+install php

        Item 3 is being worked on.
        Show
        Ralph Goers added a comment - Four items have been identified as being required to complete this. 1) URL of site source (in CMS conforming layout ---      Answer - https://svn.apache.org/repos/asf/logging/site/branches/cms/trunk 2) where to send commit mails to      Answer - commits@logging.apache.org 3) a conforming build_cms.sh script (as called by build_external.pl it is passed a source directory and a target directory) 4) we need to build+install php Item 3 is being worked on.
        Hide
        Ralph Goers added a comment -
        Item 3 has been completed.
        Show
        Ralph Goers added a comment - Item 3 has been completed.
        Hide
        Joe Schaefer added a comment -
        While I can appreciate that every community has their own preferred bag of tools to use, the fact
        is that AFAICT "twig" is yet another implementation of django templates with a textile filter. Ah,
        yeah, you could do the same thing with the supplied perl build system in about 15 lines of code.
        It'll take time for us to get around to installing php on the CMS host, but its on one of our todo lists.

        Show
        Joe Schaefer added a comment - While I can appreciate that every community has their own preferred bag of tools to use, the fact is that AFAICT "twig" is yet another implementation of django templates with a textile filter. Ah, yeah, you could do the same thing with the supplied perl build system in about 15 lines of code. It'll take time for us to get around to installing php on the CMS host, but its on one of our todo lists.
        Hide
        Joe Schaefer added a comment - - edited
        Here's how you'd do this using view.pm/path.pm:

        in path.pm:
        --------------------------------------------------------------
        my %POM_ARGS = (
           ... unravel the pom and place the args here in key=>value form
        );

        our @patterns = (
            [ qr!\.twig$!, page => \%POM_ARGS ],
        );

        1;
        --------------------------------------------------------------
        in view.pm
        --------------------------------------------------------------
        use Dotiac::DTL qw/Template *TEMPLATE_DIRS/;
        use Dotiac::DTL::Addon::markup;
        our @TEMPLATE_DIRS = "templates";

        sub page {
            my %args = @_;
            Template("content$args{path}")->render(\%args), html => \%args;
        }

        1;
        ---------------------------------------------------------------

        All you'd need to do is reorg the site so it's not arranged
        like a maven site (ie all content in content/ is merged
        in its proper place without the resources|pages directory split).
        And use {% comment %} {% endcomment %} for django comments,
        as well as repositioning the {% extends %} directive to lie on the first
        line in the file.

        HTH

        The upside is that if your site ever gets larger than a few pages,
        the perl build system is much faster than anything available in php.
        And you are using standard supported tools ;-).
        Show
        Joe Schaefer added a comment - - edited Here's how you'd do this using view.pm/path.pm: in path.pm: -------------------------------------------------------------- my %POM_ARGS = (    ... unravel the pom and place the args here in key=>value form ); our @patterns = (     [ qr!\.twig$!, page => \%POM_ARGS ], ); 1; -------------------------------------------------------------- in view.pm -------------------------------------------------------------- use Dotiac::DTL qw/Template *TEMPLATE_DIRS/; use Dotiac::DTL::Addon::markup; our @TEMPLATE_DIRS = "templates"; sub page {     my %args = @_;     Template("content$args{path}")->render(\%args), html => \%args; } 1; --------------------------------------------------------------- All you'd need to do is reorg the site so it's not arranged like a maven site (ie all content in content/ is merged in its proper place without the resources|pages directory split). And use {% comment %} {% endcomment %} for django comments, as well as repositioning the {% extends %} directive to lie on the first line in the file. HTH The upside is that if your site ever gets larger than a few pages, the perl build system is much faster than anything available in php. And you are using standard supported tools ;-).
        Hide
        Ivan Habunek added a comment -
        Originally, Twig was chosen when we were going to build the site locally and commit to svn. Now that we switched to CMS, it makes sense to use the existing Perl build system.

        I will set up the required site structure and commit it in a branch so you can try it out.

        I'm not fluent in Perl, and this is the first time i deal with Apache CMS, so I would appreciate if you would correct any stupid mistakes I make. :)
        Show
        Ivan Habunek added a comment - Originally, Twig was chosen when we were going to build the site locally and commit to svn. Now that we switched to CMS, it makes sense to use the existing Perl build system. I will set up the required site structure and commit it in a branch so you can try it out. I'm not fluent in Perl, and this is the first time i deal with Apache CMS, so I would appreciate if you would correct any stupid mistakes I make. :)
        Hide
        Ivan Habunek added a comment -
        There, I have created the required CMS structure in:
        https://svn.apache.org/repos/asf/logging/site/branches/cms/trunk/

        I tried building the site locally, but ran into some problems. I did manage to render pages via Dotiac::DTL and those works fine.
        Can you please have a look to see if I missed anything?
        Show
        Ivan Habunek added a comment - There, I have created the required CMS structure in: https://svn.apache.org/repos/asf/logging/site/branches/cms/trunk/ I tried building the site locally, but ran into some problems. I did manage to render pages via Dotiac::DTL and those works fine. Can you please have a look to see if I missed anything?
        Hide
        Joe Schaefer added a comment -
        Good job Ivan. What problems did you run into? AFAICT
        the perl code looks fine.
        Show
        Joe Schaefer added a comment - Good job Ivan. What problems did you run into? AFAICT the perl code looks fine.
        Hide
        Ralph Goers added a comment -
        What, if anything, do we do to verify that this is working? I'm also unclear if what Ivan did makes it editable through the webgui or not.
        Show
        Ralph Goers added a comment - What, if anything, do we do to verify that this is working? I'm also unclear if what Ivan did makes it editable through the webgui or not.
        Hide
        Joe Schaefer added a comment -
        I'd like to make another suggestion to you: as most of your "twig" files
        are simply applications of the textile filter to certain content, why not
        go the whole hog and make the "twig" files entirely textile? That would
        make them a lot more approachable for casual editors who have no
        clue what django templates are there for.

        The way you'd do this and preserve titles in your files is to format the
        file with headers at the top: you'd have a Title header for the page,
        and perhaps a Notice header for the license info.

        Then you would change your page sub in view.pm as follows:

        ...
        use ASF::Util qw/read_text_file/;
        ...

        sub page {
            my %args = @_;
            my $template = $args{template};
            read_text_file "content$args{path}", \%args;
            Template($template)->render(\%args), html => \%args;
        }

        and in your path.pm file you'd do this

        my %variables = (
        ...
            template => "page.html",
        );

        and in templates/page.html you'd have

        ...
           {% block title %}<title>{{ headers.title }}</title>{% endblock %}
        ...

            {{ content|textile }} <!-- where you want the page contents to appeear -->

        --------------------------
        This would completely divorce template logic from raw source content,
        which is generally a desirable attribute of a cms-based site. Then you
        could change the file extensions from ".twig" to ".tt" or whatever is
        appropriate for textile files- just update the pattern match in path.pm
        accordingly.



        Show
        Joe Schaefer added a comment - I'd like to make another suggestion to you: as most of your "twig" files are simply applications of the textile filter to certain content, why not go the whole hog and make the "twig" files entirely textile? That would make them a lot more approachable for casual editors who have no clue what django templates are there for. The way you'd do this and preserve titles in your files is to format the file with headers at the top: you'd have a Title header for the page, and perhaps a Notice header for the license info. Then you would change your page sub in view.pm as follows: ... use ASF::Util qw/read_text_file/; ... sub page {     my %args = @_;     my $template = $args{template};     read_text_file "content$args{path}", \%args;     Template($template)->render(\%args), html => \%args; } and in your path.pm file you'd do this my %variables = ( ...     template => "page.html", ); and in templates/page.html you'd have ...    {% block title %}<title>{{ headers.title }}</title>{% endblock %} ...     {{ content|textile }} <!-- where you want the page contents to appeear --> -------------------------- This would completely divorce template logic from raw source content, which is generally a desirable attribute of a cms-based site. Then you could change the file extensions from ".twig" to ".tt" or whatever is appropriate for textile files- just update the pattern match in path.pm accordingly.
        Hide
        Ivan Habunek added a comment -
        Thanks for the suggestion. I saw something similar was done in the default CMS setup for Markdown.

        I will have a look at it tomorrow morning. I think the textile filter allows raw HTML as well, this is required for our front page which is a bit too complicated for textile markup.

        As Ralph asked, is there a way to see if this actually works?
        Show
        Ivan Habunek added a comment - Thanks for the suggestion. I saw something similar was done in the default CMS setup for Markdown. I will have a look at it tomorrow morning. I think the textile filter allows raw HTML as well, this is required for our front page which is a bit too complicated for textile markup. As Ralph asked, is there a way to see if this actually works?
        Hide
        Ivan Habunek added a comment -
        After considering, I'm in favour of keeping the current setup with the django templates. I started a discussion on logging in case anybody has a problem with this.

        Regardless, we can adjust this later if required. It would be great if we could move on with setting up the test web. Do you need anything more from us?
        Show
        Ivan Habunek added a comment - After considering, I'm in favour of keeping the current setup with the django templates. I started a discussion on logging in case anybody has a problem with this. Regardless, we can adjust this later if required. It would be great if we could move on with setting up the test web. Do you need anything more from us?
        Hide
        Ralph Goers added a comment -
        Is there any update on completing this?
        Show
        Ralph Goers added a comment - Is there any update on completing this?
        Hide
        Ralph Goers added a comment -
        Is there any update on when this will be completed? We still do not know how to test.
        Show
        Ralph Goers added a comment - Is there any update on when this will be completed? We still do not know how to test.
        Hide
        Ralph Goers added a comment -
        Question: What is the name of the cms site: loggingtest

        Question: Do we need a production site enabled: Yes - we would like to test out the full process.

        Question: The final url of the source for the CMS: I believe this is the same as we told you previously - https://svn.apache.org/repos/asf/logging/site/branches/cms/trunk/

        Once testing of the site is complete it is our belief that it will be simple to rename or move loggingtest to logging. Please let us know if that is incorrect.

        Show
        Ralph Goers added a comment - Question: What is the name of the cms site: loggingtest Question: Do we need a production site enabled: Yes - we would like to test out the full process. Question: The final url of the source for the CMS: I believe this is the same as we told you previously - https://svn.apache.org/repos/asf/logging/site/branches/cms/trunk/ Once testing of the site is complete it is our belief that it will be simple to rename or move loggingtest to logging. Please let us know if that is incorrect.
        Hide
        Joe Schaefer added a comment -
        Ticket edited according to the work necessary now.
        Show
        Joe Schaefer added a comment - Ticket edited according to the work necessary now.
        Hide
        Joe Schaefer added a comment -
        DNS is propagating... there should be no problems with migrating
        loggingtest to logging.
        Show
        Joe Schaefer added a comment - DNS is propagating... there should be no problems with migrating loggingtest to logging.
        Hide
        Joe Schaefer added a comment -
        All set.
        Show
        Joe Schaefer added a comment - All set.
        Hide
        Joe Schaefer added a comment -
        I see a few charset warts in the textile stuff- was a bug
        in the build system. It'll be good practice for you guys
        to figure out how to trigger a site build, so I'll leave you
        to it (hint:

        http://www.apache.org/dev/cmsref

        is your friend).
        Show
        Joe Schaefer added a comment - I see a few charset warts in the textile stuff- was a bug in the build system. It'll be good practice for you guys to figure out how to trigger a site build, so I'll leave you to it (hint: http://www.apache.org/dev/cmsref is your friend).
        Hide
        Ivan Habunek added a comment -
        I'm still having problems with encoding. The source is in UTF-8, and that's the target encoding as well.

        It seems that UTF-8 gets mangled by the textile filter.

        To illustrate the problem, here's "Ceki Gülcü" outside and inside the textile filter:
        http://loggingtest.staging.apache.org/team-list.html

        Source:
        https://svn.apache.org/repos/asf/logging/site/branches/cms/trunk/content/team-list.twig

        So far, I haven't found why this happens, do you have any idea?
        Show
        Ivan Habunek added a comment - I'm still having problems with encoding. The source is in UTF-8, and that's the target encoding as well. It seems that UTF-8 gets mangled by the textile filter. To illustrate the problem, here's "Ceki Gülcü" outside and inside the textile filter: http://loggingtest.staging.apache.org/team-list.html Source: https://svn.apache.org/repos/asf/logging/site/branches/cms/trunk/content/team-list.twig So far, I haven't found why this happens, do you have any idea?
        Hide
        Ivan Habunek added a comment -
        I think I narrowed it down. The CMS uses Text::Textile to render textile. To use UTF-8, we need to set "char_encoding" [1] option to 0. This should prevent mangling of UTF-8 characters.

        It seems, this is already done automatically if "charset" option is set to "utf-8". See "sub charset" in [2].

        Now, the question is how can we specify the charset so that it's propagated to Text::Textile?

        [1] http://search.cpan.org/~bchoate/Text-Textile-2.12/lib/Text/Textile.pm#char_encoding(_[$encode]_)
        [2] https://svn.apache.org/repos/infra/websites/cms/build/lib/Text/Textile.pm
        Show
        Ivan Habunek added a comment - I think I narrowed it down. The CMS uses Text::Textile to render textile. To use UTF-8, we need to set "char_encoding" [1] option to 0. This should prevent mangling of UTF-8 characters. It seems, this is already done automatically if "charset" option is set to "utf-8". See "sub charset" in [2]. Now, the question is how can we specify the charset so that it's propagated to Text::Textile? [1] http://search.cpan.org/~bchoate/Text-Textile-2.12/lib/Text/Textile.pm#char_encoding(_ [$encode]_) [2] https://svn.apache.org/repos/infra/websites/cms/build/lib/Text/Textile.pm
        Hide
        Joe Schaefer added a comment -
        Please see https://svn.apache.org/repos/infra/websites/cms/build/lib/Dotiac/DTL/Addon/markup.pm
        where I recently changed the textile call to include a charset argument. If that doesn't work currently,
        please fiddle with the args to new() to get something working there on a local build of your site and
        tell me what the patch is so I can apply it to the cms. Thanks.
        Show
        Joe Schaefer added a comment - Please see https://svn.apache.org/repos/infra/websites/cms/build/lib/Dotiac/DTL/Addon/markup.pm where I recently changed the textile call to include a charset argument. If that doesn't work currently, please fiddle with the args to new() to get something working there on a local build of your site and tell me what the patch is so I can apply it to the cms. Thanks.
        Hide
        Ivan Habunek added a comment -
        This patch fixes it for me locally.

        The docs say that escaping should automatically be disabled when given utf-8 charset, but for some reason it is not. So I just disabled it explicitly.
        Show
        Ivan Habunek added a comment - This patch fixes it for me locally. The docs say that escaping should automatically be disabled when given utf-8 charset, but for some reason it is not. So I just disabled it explicitly.
        Hide
        Joe Schaefer added a comment -
        Patch applied- please trigger a full site build and recheck the charset.
        Show
        Joe Schaefer added a comment - Patch applied- please trigger a full site build and recheck the charset.
        Hide
        Ivan Habunek added a comment -
        Looks good. Thanks!
        Show
        Ivan Habunek added a comment - Looks good. Thanks!

          People

          • Assignee:
            Joe Schaefer
            Reporter:
            Ralph Goers
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development