[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-7643":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":16,"stars7d":17,"stars30d":18,"stars90d":16,"forks30d":16,"starsTrendScore":16,"compositeScore":19,"rankGlobal":10,"rankLanguage":10,"license":20,"archived":21,"fork":21,"defaultBranch":22,"hasWiki":23,"hasPages":23,"topics":24,"createdAt":10,"pushedAt":10,"updatedAt":25,"readmeContent":26,"aiSummary":27,"trendingCount":16,"starSnapshotCount":16,"syncStatus":28,"lastSyncTime":29,"discoverSource":30},7643,"liquid","Shopify\u002Fliquid","Shopify","Liquid markup language. Safe, customer facing template language for flexible web apps. ","https:\u002F\u002Fshopify.github.io\u002Fliquid\u002F",null,"Ruby",11806,1526,722,325,0,4,23,44.55,"MIT License",false,"main",true,[],"2026-06-12 02:01:42","[![Build status](https:\u002F\u002Fgithub.com\u002FShopify\u002Fliquid\u002Factions\u002Fworkflows\u002Fliquid.yml\u002Fbadge.svg)](https:\u002F\u002Fgithub.com\u002FShopify\u002Fliquid\u002Factions\u002Fworkflows\u002Fliquid.yml)\n[![Inline docs](http:\u002F\u002Finch-ci.org\u002Fgithub\u002FShopify\u002Fliquid.svg?branch=master)](http:\u002F\u002Finch-ci.org\u002Fgithub\u002FShopify\u002Fliquid)\n\n# Liquid template engine\n\n* [Contributing guidelines](CONTRIBUTING.md)\n* [Version history](History.md)\n* [Liquid documentation from Shopify](https:\u002F\u002Fshopify.dev\u002Fdocs\u002Fapi\u002Fliquid)\n* [Liquid Wiki at GitHub](https:\u002F\u002Fgithub.com\u002FShopify\u002Fliquid\u002Fwiki)\n* [Website](http:\u002F\u002Fliquidmarkup.org\u002F)\n\n## Introduction\n\nLiquid is a template engine which was written with very specific requirements:\n\n* It has to have beautiful and simple markup. Template engines which don't produce good looking markup are no fun to use.\n* It needs to be non evaling and secure. Liquid templates are made so that users can edit them. You don't want to run code on your server which your users wrote.\n* It has to be stateless. Compile and render steps have to be separate so that the expensive parsing and compiling can be done once and later on you can just render it passing in a hash with local variables and objects.\n\n## Why you should use Liquid\n\n* You want to allow your users to edit the appearance of your application but don't want them to run **insecure code on your server**.\n* You want to render templates directly from the database.\n* You like smarty (PHP) style template engines.\n* You need a template engine which does HTML just as well as emails.\n* You don't like the markup of your current templating engine.\n\n## What does it look like?\n\n```html\n\u003Cul id=\"products\">\n  {% for product in products %}\n    \u003Cli>\n      \u003Ch2>{{ product.name }}\u003C\u002Fh2>\n      Only {{ product.price | price }}\n\n      {{ product.description | prettyprint | paragraph }}\n    \u003C\u002Fli>\n  {% endfor %}\n\u003C\u002Ful>\n```\n\n## How to use Liquid\n\nInstall Liquid by adding `gem 'liquid'` to your gemfile.\n\nLiquid supports a very simple API based around the Liquid::Template class.\nFor standard use you can just pass it the content of a file and call render with a parameters hash.\n\n```ruby\n@template = Liquid::Template.parse(\"hi {{name}}\") # Parses and compiles the template\n@template.render('name' => 'tobi')                # => \"hi tobi\"\n```\n\n### Concept of Environments\n\nIn Liquid, a \"Environment\" is a scoped environment that encapsulates custom tags, filters, and other configurations. This allows you to define and isolate different sets of functionality for different contexts, avoiding global overrides that can lead to conflicts and unexpected behavior.\n\nBy using environments, you can:\n\n1. **Encapsulate Logic**: Keep the logic for different parts of your application separate.\n2. **Avoid Conflicts**: Prevent custom tags and filters from clashing with each other.\n3. **Improve Maintainability**: Make it easier to manage and understand the scope of customizations.\n4. **Enhance Security**: Limit the availability of certain tags and filters to specific contexts.\n\nWe encourage the use of Environments over globally overriding things because it promotes better software design principles such as modularity, encapsulation, and separation of concerns.\n\nHere's an example of how you can define and use Environments in Liquid:\n\n```ruby\nuser_environment = Liquid::Environment.build do |environment|\n  environment.register_tag(\"renderobj\", RenderObjTag)\nend\n\nLiquid::Template.parse(\u003C\u003C~LIQUID, environment: user_environment)\n  {% renderobj src: \"path\u002Fto\u002Fmodel.obj\" %}\nLIQUID\n```\n\nIn this example, `RenderObjTag` is a custom tag that is only available within the `user_environment`.\n\nSimilarly, you can define another environment for a different context, such as email templates:\n\n```ruby\nemail_environment = Liquid::Environment.build do |environment|\n  environment.register_tag(\"unsubscribe_footer\", UnsubscribeFooter)\nend\n\nLiquid::Template.parse(\u003C\u003C~LIQUID, environment: email_environment)\n  {% unsubscribe_footer %}\nLIQUID\n```\n\nBy using Environments, you ensure that custom tags and filters are only available in the contexts where they are needed, making your Liquid templates more robust and easier to manage. For smaller projects, a global environment is available via `Liquid::Environment.default`.\n\n### Error Modes\n\nSetting the error mode of Liquid lets you specify how strictly you want your templates to be interpreted.\nNormally the parser is very lax and will accept almost anything without error. Unfortunately this can make\nit very hard to debug and can lead to unexpected behaviour.\n\nLiquid also comes with different parsers that can be used when editing templates to give better error messages\nwhen templates are invalid. You can enable this new parser like this:\n\n```ruby\nLiquid::Environment.default.error_mode = :strict2 # Raises a SyntaxError when invalid syntax is used in all tags\nLiquid::Environment.default.error_mode = :strict  # Raises a SyntaxError when invalid syntax is used in some tags\nLiquid::Environment.default.error_mode = :warn    # Adds strict errors to template.errors but continues as normal\nLiquid::Environment.default.error_mode = :lax     # The default mode, accepts almost anything.\n```\n\nIf you want to set the error mode only on specific templates you can pass `:error_mode` as an option to `parse`:\n```ruby\nLiquid::Template.parse(source, error_mode: :strict)\n```\nThis is useful for doing things like enabling strict mode only in the theme editor.\n\nIt is recommended that you enable `:strict` or `:warn` mode on new apps to stop invalid templates from being created.\nIt is also recommended that you use it in the template editors of existing apps to give editors better error messages.\n\n### Undefined variables and filters\n\nBy default, the renderer doesn't raise or in any other way notify you if some variables or filters are missing, i.e. not passed to the `render` method.\nYou can improve this situation by passing `strict_variables: true` and\u002For `strict_filters: true` options to the `render` method.\nWhen one of these options is set to true, all errors about undefined variables and undefined filters will be stored in `errors` array of a `Liquid::Template` instance.\nHere are some examples:\n\n```ruby\ntemplate = Liquid::Template.parse(\"{{x}} {{y}} {{z.a}} {{z.b}}\")\ntemplate.render({ 'x' => 1, 'z' => { 'a' => 2 } }, { strict_variables: true })\n#=> '1  2 ' # when a variable is undefined, it's rendered as nil\ntemplate.errors\n#=> [#\u003CLiquid::UndefinedVariable: Liquid error: undefined variable y>, #\u003CLiquid::UndefinedVariable: Liquid error: undefined variable b>]\n```\n\n```ruby\ntemplate = Liquid::Template.parse(\"{{x | filter1 | upcase}}\")\ntemplate.render({ 'x' => 'foo' }, { strict_filters: true })\n#=> '' # when at least one filter in the filter chain is undefined, a whole expression is rendered as nil\ntemplate.errors\n#=> [#\u003CLiquid::UndefinedFilter: Liquid error: undefined filter filter1>]\n```\n\nIf you want to raise on a first exception instead of pushing all of them in `errors`, you can use `render!` method:\n\n```ruby\ntemplate = Liquid::Template.parse(\"{{x}} {{y}}\")\ntemplate.render!({ 'x' => 1}, { strict_variables: true })\n#=> Liquid::UndefinedVariable: Liquid error: undefined variable y\n```\n\n### Usage tracking\n\nTo help track usages of a feature or code path in production, we have released opt-in usage tracking. To enable this, we provide an empty `Liquid:: Usage.increment` method which you can customize to your needs. The feature is well suited to https:\u002F\u002Fgithub.com\u002FShopify\u002Fstatsd-instrument. However, the choice of implementation is up to you.\n\nOnce you have enabled usage tracking, we recommend reporting any events through Github Issues that your system may be logging. It is highly likely this event has been added to consider deprecating or improving code specific to this event, so please raise any concerns.\n","Liquid 是一种用于灵活 Web 应用的模板语言，特别适合面向客户的安全场景。其核心功能包括简洁美观的标记语法、非执行和安全特性以及无状态设计，使得解析和编译可以分离，从而提高效率。Liquid 适用于需要让用户自定义应用外观但又不希望用户在服务器上运行不安全代码的情况，同时也支持直接从数据库渲染模板，并且能够很好地处理 HTML 和电子邮件内容。通过使用 Ruby 的 gem 包进行安装，开发者可以轻松地将 Liquid 集成到项目中，利用其提供的简单 API 来解析和渲染模板。此外，Liquid 引入了环境的概念，允许为不同的应用场景封装自定义标签和过滤器，从而避免全局覆盖导致的冲突，增强了代码的可维护性和安全性。",2,"2026-06-11 03:13:30","top_language"]