× Warning! This forum is in archival status. New contributions may not work.
Presentation layer cache
  • Vote Up0Vote Down Andrey PodshivalovAndrey Podshivalov
    Posts: 1,526Member, Administrator, Sourcefabric Team
    hi,

    id like to introduce my vision about campsite cache.

    As you know the Campsite support db layer caching. The first cache adapter was APC. It allows to cache sql queries results in a memory. It decrease site response about 2x. Looks good but we have some principal problems. 1. APC is not enabled on shared hosting. 2. APC is unstable on Virtual Servers which based on linux containers (like openvz/virtuozzo, lxc). 3. DB layer caching requires very punctual db queries programming. Unfortunately, new introduced functionality brings new db cache issues (unimplemented cache clear triggers) or/and new uncached queries.
    To resolve first two problem I've implemented file based adapter but this solution can not be used: cache size can grow more than 20Mb. In this case the file cache decelerates the site response.

    So, I'm thinking about presentation layer caching that based on file system. It resolves all principal db layer cache problems but there is another presentation layer specific problem: the rendered page has different logic blocks with different cache lifetime requirements (e.g. article, polls, comments, informers).
    I'm going to resolve it via small template refactoring:
    1. Each logic content block should be moved into separate template file.
    2. The template file can contain cache specific header with lifetime information.

    The file system organization will replicate campsite content structure: publication/lang/issue/section/article

    Case scenario: author has changed article #2354 in section # 12, issue #109 After then cache manager is cleaning up 3 folders for issue 109, section 12 and article 2354 (109, 109/12 and 109/12/2354). It looks simple to implement.

    Also I'd like to cache the images from getimage output.

    That's main idea. Suggestions, ideas, criticism absolutely welcome.
  • 17 Comments sorted by
  • Hi Andrey,

    Do not forget Smarty caching capability. It is file-based and
    implements a good level of flexibility, you can set selective template
    caching where you would say "hey article.tpl template is gonna be
    cached and re-created once a day and home.tpl is not gonna be cached
    at all" or even you could say "blocks for main news and headlines in
    home.tpl are gonna be cached and re-created every 1 hour, while blocks
    for latest comments and twitts also in home.tpl won't be cached at
    all".

    How to handle and control this behavior from Campsite is the question
    as it is up to the templates developer in the first case.


    On Fri, Sep 10, 2010 at 11:55 AM, Andrey Podshivalov
    <campsite-dev@lists.sourcefabric.org> wrote:
    >
    > hi,
    >
    > id like to introduce my vision about campsite cache.
    >
    > As you know the Campsite support db layer caching. The first cache adapter was APC. It allows to cache sql queries results in a memory. It decrease site response about 2x. Looks good but we have some principal problems. 1. APC is not enabled on shared hosting. 2. APC is unstable on Virtual Servers which based on linux containers (like openvz/virtuozzo, lxc). 3. DB layer caching requires very punctual db queries programming. Unfortunately, new introduced functionality brings new db cache issues (unimplemented cache clear triggers) or/and new uncached queries.
    > To resolve first two problem I've implemented file based adapter but this solution can not be used: cache size can grow more than 20Mb. In this case the file cache decelerates the site response.
    >
    > So, I'm thinking about presentation layer caching that based on file system. It resolves all principal db layer cache problems but there is another presentation layer specific problem: the rendered page has different logic blocks with different cache lifetime requirements (e.g. article, polls, comments, informers).
    > I'm going to resolve it via small template refactoring:
    > 1. Each logic content block should be moved into separate template file.
    > 2. The template file can contain cache specific header with lifetime information.
    >
    > The file system organization will replicate campsite content structure: publication/lang/issue/section/article
    >
    > Case scenario: author has changed article #2354 in section # 12, issue #109 After then cache manager is cleaning up 3 folders for issue 109, section 12 and article 2354 (109, 109/12 and 109/12/2354). It looks simple to implement.
    >
    > Also I'd like to cache the images from getimage output.
    >
    > That's main idea. Suggestions, ideas, criticism absolutely welcome.
    >


    --
    Holman Romero
    Senior Software Engineer, Sourcefabric
    holman.romero@sourcefabric.org

    Salvátorská 10
    110 00 Praha 1, Czech Republic
    +420 607 133 896

    http://www.sourcefabric.org
  • Vote Up0Vote Down Andrey PodshivalovAndrey Podshivalov
    Posts: 1,526Member, Administrator, Sourcefabric Team
    Holman Romero wrote on Fri, 10 September 2010 18:02

    How to handle and control this behavior from Campsite is the question
    as it is up to the templates developer in the first case.


    I'm thinking about Template manger. In additional to template editing we can add cache lifetime property for each template. After saving template the Template manager refreshes template cache lifetime settings document for Smarty lib.
  • For what it's worth, the NYTimes uses Varnish, and they wrote this blog entry about it on their developer blog: http://open.blogs.nytimes.com/2010/09/15/using-varnish-so-ne ws-doesnt-break-your-server/
    Douglas Arellanes
    Director of Innovation
    Sourcefabric, o.p.s.

    Find a way or make one.
  • Vote Up0Vote Down Paul BaranowskiPaul Baranowski
    Posts: 389Member, Administrator, Sourcefabric Team
    I would agree with this - we dont really want to invent our own caching
    system. There are tons of caching systems already built, we should use one
    of them. What is preventing us from doing that? What are the scenarios
    that we need to refresh different parts of the page at different intervals
    (i.e. why not just set a global timeout of 1-5 min or so)? And what about
    serving code to the client so that it fetches different content instead of
    doing it server side? Andrey - you mention that "20MB" of cache is too
    big. Is that number correct, because that seems like a very small number
    for a cache? What does it mean to be "too big"? And is that in RAM or on
    the file system? No matter which one, it seems like a very small number for
    a cache. (e.g. the Java interpreter uses more space than that in memory).

    Paul Baranowski
    Chief Technology Officer, Sourcefabric

    paul.baranowski@sourcefabric.org
    +1 (416) 619-0874 (Office)
    +1 (416) 832-6436 (Cell)
    Toronto, ON, Canada

    http://sourcefabric.org
    Skype: paulbaranowski


    On Wed, Sep 15, 2010 at 9:56 AM, Douglas Arellanes <
    campsite-dev@lists.sourcefabric.org> wrote:

    > For what it's worth, the NYTimes uses Varnish, and they wrote this blog
    > entry about it on their developer blog: http://open.blogs.nytimes.com/2010/09/15/using-varnish-so-ne
    > ws-doesnt-break-your-server/< http://open.blogs.nytimes.com/2010/09/15/using-varnish-so-ne ws-doesnt-break-your-server/>
    >

  • "1. APC is not enabled on shared hosting. 2. APC is unstable on Virtual
    Servers which based on linux containers (like openvz/virtuozzo, lxc)."
    Writing a Campsite driver for another PHP cache engine (xcache, eaccelerator
    etc.) is a *1 hour* time work. Isn't any of these engines available on
    shared hosting?

    "Unfortunately, new introduced functionality brings new db cache issues
    (unimplemented cache clear triggers) or/and new uncached queries."
    Data access caching is transparent, for any new table in the db structure
    you just need to inherit from DatabaseObject. There are indeed other data
    structures like lists of objects that need manual refreshing on data change
    but from now on Campsite is kind of in just maintenance mode, it's not worth
    putting too much work in it.

    "1. Each logic content block should be moved into separate template file."
    You can't force web designers to do this kind of structuring, I'm sure we
    would hear cries of madness.

    "2. The template file can contain cache specific header with lifetime
    information."
    Don't forget that each template is used for serving multiple pages. E.g.:
    section.tpl displays any section based on parameters so you would have to
    set the cache specific header based on URL, not template file.

    "The file system organization will replicate campsite content structure:
    publication/lang/issue/section/article"
    Again, cries of madness from web-designers. Plus, what do you do with blocks
    that are common to all pages?

    Anyway, as Paul said, I don't see the point in putting our resources to
    build a custom cache instead of using existing solutions.


    Mugur Rus
    Senior Software Developer, Sourcefabric
    mugur.rus@sourcefabric.org

    Cluj-Napoca, Romania
    +40 (0)720 528408
    Skype: mugur_rus

    http://www.sourcefabric.org
    http://www.twitter.com/Sourcefabric


    On Fri, Sep 10, 2010 at 12:55 PM, Andrey Podshivalov <
    campsite-dev@lists.sourcefabric.org> wrote:

    > hi,
    >
    > id like to introduce my vision about campsite cache.
    >
    > As you know the Campsite support db layer caching. The first cache adapter
    > was APC. It allows to cache sql queries results in a memory. It decrease
    > site response about 2x. Looks good but we have some principal problems. 1.
    > APC is not enabled on shared hosting. 2. APC is unstable on Virtual Servers
    > which based on linux containers (like openvz/virtuozzo, lxc). 3. DB layer
    > caching requires very punctual db queries programming. Unfortunately, new
    > introduced functionality brings new db cache issues (unimplemented cache
    > clear triggers) or/and new uncached queries.
    > To resolve first two problem I've implemented file based adapter but this
    > solution can not be used: cache size can grow more than 20Mb. In this case
    > the file cache decelerates the site response.
    >
    > So, I'm thinking about presentation layer caching that based on file
    > system. It resolves all principal db layer cache problems but there is
    > another presentation layer specific problem: the rendered page has different
    > logic blocks with different cache lifetime requirements (e.g. article,
    > polls, comments, informers).
    > I'm going to resolve it via small template refactoring:
    > 1. Each logic content block should be moved into separate template file.
    > 2. The template file can contain cache specific header with lifetime
    > information.
    >
    > The file system organization will replicate campsite content structure:
    > publication/lang/issue/ section/article
    >
    > Case scenario: author has changed article #2354 in section # 12, issue #109
    > After then cache manager is cleaning up 3 folders for issue 109, section 12
    > and article 2354 (109, 109/12 and 109/12/2354). It looks simple to
    > implement.
    >
    > Also I'd like to cache the images from getimage output.
    >
    > That's main idea. Suggestions, ideas, criticism absolutely welcome.
    >
    >

  • Vote Up0Vote Down Andrey PodshivalovAndrey Podshivalov
    Posts: 1,526Member, Administrator, Sourcefabric Team
    Paul Baranowski wrote on Thu, 16 September 2010 00:34
    I would agree with this - we dont really want to invent our own caching
    system. There are tons of caching systems already built, we should use one
    of them.

    Do you mean an external cache system like Varnish? Then this systems isn't accessible on shared hosting and it doesn't resolve the problem on dedicated. I'm using for more than 10 sites the Squid as site accelerator (I've tested both Varnish and Squid but Squid looks more stable) with cache lifetime 10 mins. It works fine for human visitors who views usually the same latest content but doesn't for search/spam crawlers which retrieves any content. In addition I have to migrate sites on shared hosting where apc or any site accelerators are missing.

    Quote:

    What is preventing us from doing that? What are the scenarios
    that we need to refresh different parts of the page at different intervals
    (i.e. why not just set a global timeout of 1-5 min or so)? And what about
    serving code to the client so that it fetches different content instead of
    doing it server side?

    About global timeout. As I said it doesn't help for search crowlers and there is another problem - authors would like to see the modifications on the frontend w/o waiting. With Squid the author has to press Shift+Reload (just Reload isn't working) to tell Squid to fresh cache.

    Quote:

    Andrey - you mention that "20MB" of cache is too
    big. Is that number correct, because that seems like a very small number
    for a cache? What does it mean to be "too big"? And is that in RAM or on
    the file system?

    It's a file-based cache adapter.

    Quote:

    No matter which one, it seems like a very small number for
    a cache. (e.g. the Java interpreter uses more space than that in memory).


    It matters for php. The cache file should be included in each request. I've tested different formats the best result if cache is presented as raw php array in one file. Unserialization takes after 10 mb more than 1 sec. The same situationin in case separation of each db query result into different file (campsite generates 700-1500 db queries per page request)

    So php format looks the faster but php is interpreter and that 20MB should be interpreted on each request (opcode doesn't help - file is not statical).
    The best results I've got on file less than 10 mb.

    Any other solutions like any db library (sqlite, berkleydb) or mysql as storage container doesn't look interesting for me because as I said APC speeds up about x2 but I need more than APC allows.

  • Vote Up0Vote Down Andrey PodshivalovAndrey Podshivalov
    Posts: 1,526Member, Administrator, Sourcefabric Team
    Mugur Rus wrote on Thu, 16 September 2010 10:22
    "1. APC is not enabled on shared hosting. 2. APC is unstable on Virtual
    Servers which based on linux containers (like openvz/virtuozzo, lxc)."
    Writing a Campsite driver for another PHP cache engine (xcache, eaccelerator
    etc.) is a *1 hour* time work. Isn't any of these engines available on
    shared hosting?


    You should understand the differences between opcode caching and data caching. Each shared hosting has some opcode cacher (apc, zend etc) but with disabled data caching

    Quote:

    "Unfortunately, new introduced functionality brings new db cache issues
    (unimplemented cache clear triggers) or/and new uncached queries."
    Data access caching is transparent, for any new table in the db structure
    you just need to inherit from DatabaseObject. There are indeed other data
    structures like lists of objects that need manual refreshing on data change
    but from now on Campsite is kind of in just maintenance mode, it's not worth
    putting too much work in it.

    Mugur, just test the latest version and you will be surprised that about 10% queries are missed in the cache on each same request.

    Quote:

    Anyway, as Paul said, I don't see the point in putting our resources to
    build a custom cache instead of using existing solutions.


    Guys, I'm waiting for constructive suggestions. As I said I'm using the Squid but I'm not happy how Campsite loads the server anyway. I don't see any other solution except campsite specific cache implementation.
  • Really I am 100% with Andrey
    use MYsql for Cache is load your server and use memory you not need. also the server become expensive because you need more ram

    About I read before 20 megas memory. ????? How use 20 megas memory for cache. If is impossible

    Mysql is never a good option for cache
  • "You should understand the differences between opcode caching and data
    caching. Each shared hosting has some opcode cacher (apc, zend etc) but with
    disabled data caching"
    Andrey, you were talking about the db layer caching, here are your words: "As
    you know the Campsite support db layer caching." Also, you mentioned APC was
    disabled on shared hosting, *not* data caching: "1. APC is not enabled on
    shared hosting". That's why I asked whether other data caching engines were
    enabled.

    You did not talk about opcode caching and my answer also implied data
    caching.

    Publications that have high traffic and need data caching should not use
    crappy shared hosting. Period. As I remember CPP sites use APC data cache
    and they are on shared hosting.

    "Mugur, just test the latest version and you will be surprised that about
    10% queries are missed in the cache on each same request."
    Will check that.


    Mugur Rus
    Senior Software Developer, Sourcefabric
    mugur.rus@sourcefabric.org

    Cluj-Napoca, Romania
    +40 (0)720 528408
    Skype: mugur_rus

    http://www.sourcefabric.org
    http://www.twitter.com/Sourcefabric


    On Thu, Sep 16, 2010 at 10:41 AM, Andrey Podshivalov <
    campsite-dev@lists.sourcefabric.org> wrote:

    > Mugur Rus wrote on Thu, 16 September 2010 10:22
    >
    > "1. APC is not enabled on shared hosting. 2. APC is unstable on Virtual
    > Servers which based on linux containers (like openvz/virtuozzo, lxc)."
    > Writing a Campsite driver for another PHP cache engine (xcache,
    > eaccelerator
    > etc.) is a *1 hour* time work. Isn't any of these engines available on
    > shared hosting?
    >
    >
    >
    > You should understand the differences between opcode caching and data
    > caching. Each shared hosting has some opcode cacher (apc, zend etc) but with
    > disabled data caching
    >
    > Quote:
    >
    >
    > "Unfortunately, new introduced functionality brings new db cache issues
    > (unimplemented cache clear triggers) or/and new uncached queries."
    > Data access caching is transparent, for any new table in the db structure
    > you just need to inherit from DatabaseObject. There are indeed other data
    > structures like lists of objects that need manual refreshing on data change
    > but from now on Campsite is kind of in just maintenance mode, it's not
    > worth
    > putting too much work in it.
    >
    >
    > Mugur, just test the latest version and you will be surprised that about
    > 10% queries are missed in the cache on each same request.
    >
    > Quote:
    >
    >
    > Anyway, as Paul said, I don't see the point in putting our resources to
    > build a custom cache instead of using existing solutions.
    >
    >
    >
    > Guys, I'm waiting for constructive suggestions. As I said I'm using the
    > Squid but I'm not happy how Campsite loads the server anyway. I don't see
    > any other solution except campsite specific cache implementation.
    >
    >

  • Vote Up0Vote Down Andrey PodshivalovAndrey Podshivalov
    Posts: 1,526Member, Administrator, Sourcefabric Team
    Mugur Rus wrote on Thu, 16 September 2010 12:26

    Publications that have high traffic and need data caching should not use
    crappy shared hosting. Period. As I remember CPP sites use APC data cache
    and they are on shared hosting.

    Several sites are running on VPS where I can not use APC data cache - It's too unstable. Other sites are working on shared hosting w/o enabled APC data caching.
  • Vote Up0Vote Down Paul BaranowskiPaul Baranowski
    Posts: 389Member, Administrator, Sourcefabric Team
    Hi Andrey-
    How about "memcached" - any reason this wouldnt work?


    Paul Baranowski
    Chief Technology Officer, Sourcefabric

    paul.baranowski@sourcefabric.org
    +1 (416) 832-6436 (Cell)
    Toronto, ON, Canada

    http://sourcefabric.org
    Skype: paulbaranowski


    On Thu, Sep 16, 2010 at 6:41 AM, Andrey Podshivalov <
    campsite-dev@lists.sourcefabric.org> wrote:

    > Mugur Rus wrote on Thu, 16 September 2010 12:26
    >
    >
    > Publications that have high traffic and need data caching should not use
    > crappy shared hosting. Period. As I remember CPP sites use APC data cache
    > and they are on shared hosting.
    >
    >
    > Several sites are running on VPS where I can not use APC data cache - It's
    > too unstable. Other sites are working on shared hosting w/o enabled APC data
    > caching.
    >

  • Vote Up0Vote Down Andrey PodshivalovAndrey Podshivalov
    Posts: 1,526Member, Administrator, Sourcefabric Team
    hi Paul,

    memcacached on vps doesn't resolve APC issue. The problem is memory management on the linux containers like Virtuozzo/OpenVZ or LXC. The containers tells to programs there is enough free memory but the program can not allocate and generates segfault. It's vps specific problem, not APC. Also on shared hosting the memcached isn't available usually.

    Btw, I've implemented the template caching and now is testing on several production sites. Looks very promised: the template caching accelerates site response about 5x-12x. It depends on how many code in a template has been excluded from caching. I'll announce more details a bit later.
  • Vote Up0Vote Down Andrey PodshivalovAndrey Podshivalov
    Posts: 1,526Member, Administrator, Sourcefabric Team
    Finally the template cache has been implemented and tested.
    I'd like to explain how template caching works.

    To exclude dynamic stuff I've added {{ dynamic }} block. Any code inside dynamic block will be excluded form cache and rendered on each request.

    It was first version of template cache handler. It had been working fine but without so many dynamic excluded parts. For given example the cache accelerates just about 2x times than uncached.

    That's not fine for me. I'd like more Smile and I've implemented the second template cache handler version with multirendering support. It allows to render included sub-templates by separate rendering process with personal cache settings. The next version contains new function {{ render }}

    Full specification:
    {{ render file="template_name" [issue=off|issueid] [section=off|sectionid] [article=off|articleid] [params=paremeters] [cache=secs] }}

    where

    file: template filename
    issue: to cache for any issue or for an issue with issueid
    section: to cache for any section or for a section with sectionid
    article: to cache for any article or for a article with articleid
    params: specify additional parameters
    cache: overwrite the cache settings in template manager

    Let's see on example.
    Here is the layout of standard section page.
    index.php/fa/35/0/

    We need to exclude from caching some dynamic stuff:
    1. Most popular list
    2. Most commented list
    3. External informers
    4. Template contains article list pagination.

    Let's define some parameters for dynamic stuff:
    Most popular article list is defined for issue only.
    Most commented article list is defined for all articles in any issue
    Informers should be included on each request
    Pagination generates links like http://site/en/pub/issue/section/?page=n

    Most popular and commented lists should be cached for 600 sec
    The main template section.tpl should be cached for 30 days

    Let's do it.

    The cache lifetime for main template can be defined in Template manager:
    index.php/fa/36/0/
    Most popular list:
    {{ render file="most_popular.tpl" section=off cache=600 }}

    Most commented list:
    {{ render file="most_commented.tpl" issue=off section=off cache=600 }}

    Informers:
    {{ dynamic }}
    {{ php }} inclide 'informer1.php'; {{ php }}
    {{ /dynamic }}

    Section article list with pagination:
    {{ render file="section_list.tpl" params=$campsite->url->get_parameter(page) }}

    On article changing or issue publishing/unpublishing the cache manager cleans outdated cached template. Cleaning algorithm based on campsite specific parameters: language, publication, issue, section, article, template, additional params.

    Some testing results (site response):
    belmarket.by - shared hosting/
    Rendering time w/o caching: 3200 ms
    Rendering time w/ caching: 200 ms (11x)

    newsabah.com - vps
    Rendering time w/o caching: 300 ms
    Rendering time w/ caching: 35 ms (8,5x)

    nv-online.info - vps
    Rendering time w/o caching: 2100 ms
    Rendering time w/ caching: 40 ms (50x!!!)

    well, I'm happy now Smile
  • Vote Up0Vote Down Sava TatićSava Tatić
    Posts: 113Member, Administrator, Sourcefabric Team
    Congratulations, Andrey.

    So this is already committed into the 3.5 branch? Will users have to wait for
    it to take advantage of it?

    All the best,

    Sava

    On Friday, October 08, 2010 16:13:14 Andrey Podshivalov wrote:
    > Finally the template cache has been implemented and tested.
    > I'd like to explain how template caching works.
    >
    > To exclude dynamic stuff I've added {{ dynamic }} block. Any code inside
    > dynamic block will be excluded form cache and rendered on each request.
    >
    > It was first version of template cache handler. It had been working fine
    > but without so many dynamic excluded parts. For given example the cache
    > accelerates just about 2x times than uncached.
    >
    > That's not fine for me. I'd like more and I've implemented the second
    > template cache handler version with multirendering support. It allows to
    > render included sub-templates by separate rendering process with personal
    > cache settings. The next version contains new function {{ render }}
    >
    > Full specification:
    > {{ render file="template_name" [issue=off|issueid] [section=off|sectionid]
    > [article=off|articleid] [params=paremeters] [cache=secs] }}
    >
    > where
    >
    > file: template filename
    > issue: to cache for any issue or for an issue with issueid
    > section: to cache for any section or for a section with sectionid
    > article: to cache for any article or for a article with articleid
    > params: specify additional parameters
    > cache: overwrite the cache settings in template manager
    >
    > Let's see on example.
    > Here is the layout of standard section page.
    >
    >
    > We need to exclude from caching some dynamic stuff:
    > 1. Most popular list
    > 2. Most commented list
    > 3. External informers
    > 4. Template contains article list pagination.
    >
    > Let's define some parameters for dynamic stuff:
    > Most popular article list is defined for issue only.
    > Most commented article list is defined for all articles in any issue
    > Informers should be included on each request
    > Pagination generates links like http://site/en/pub/issue/section/?page=n
    >
    > Most popular and commented lists should be cached for 600 sec
    > The main template section.tpl should be cached for 30 days
    >
    > Let's do it.
    >
    > The cache lifetime for main template can be defined in Template manager:
    >
    > Most popular list:
    > {{ render file="most_popular.tpl" section=off cache=600 }}
    >
    > Most commented list:
    > {{ render file="most_commented.tpl" issue=off section=off cache=600 }}
    >
    > Informers:
    > {{ dynamic }}
    > {{ php }} inclide 'informer1.php'; {{ php }}
    > {{ /dynamic }}
    >
    > Section article list with pagination:
    > {{ render file="section_list.tpl"
    > params=$campsite->url->get_parameter(page) }}
    >
    > On article changing or issue publishing/unpublishing the cache manager
    > cleans outdated cached template. Cleaning algorithm based on campsite
    > specific parameters: language, publication, issue, section, article,
    > template, additional params.
    >
    > Some testing results (site response):
    > belmarket.by - shared hosting/
    > Rendering time w/o caching: 3200 ms
    > Rendering time w/ caching: 200 ms (11x)
    >
    > newsabah.com - vps
    > Rendering time w/o caching: 300 ms
    > Rendering time w/ caching: 35 ms (8,5x)
    >
    > nv-online.info - vps
    > Rendering time w/o caching: 2100 ms
    > Rendering time w/ caching: 40 ms (50x!!!)
    >
    > well, I'm happy now
    >
    >
    > To participate in the discussion, go here:
    > http://forum.sourcefabric.org/index.php?t=rview&frm_id=1 1

    --
    Sava Tatić
    Managing Director, Sourcefabric o.p.s.
    sava.tatic@sourcefabric.org

    Salvátorská 10
    110 00 Praha 1, Czech Republic
    +420222362540
    +420602653104 (mobile)
    Skype: tictactatic

    http://www.sourcefabric.org
    http://www.twitter.com/Sourcefabric
  • Vote Up0Vote Down Andrey PodshivalovAndrey Podshivalov
    Posts: 1,526Member, Administrator, Sourcefabric Team
    yes, it's in the repository already and will be available in 3.5 release
  • And would this be interesting for upstream Smarty developers, or is it specific to Campsite ?
    Douglas Arellanes
    Director of Innovation
    Sourcefabric, o.p.s.

    Find a way or make one.
  • Vote Up0Vote Down Andrey PodshivalovAndrey Podshivalov
    Posts: 1,526Member, Administrator, Sourcefabric Team
    Just for campsite. There isn't any smarty trick.