Add liquid processor configuration file option to support custom inline and block tags

[safinilnur]

Issue: #124

• --liquid-processor-configuration {path to JSON file}

Specifies the path to a JSON file with LiquidProcessorConfiguration, containing InlineTags and BlockTags arrays used to register custom Liquid tags during parsing.

Example:

{
  "InlineTags": ["resources", "link", "script", "style"],
  "BlockTags": ["scriptblock", "styleblock"]
}

[hishamco]

Before I dig into the details, does that mean all the custom tags and filters in OC are not recognized? If yes, give some examples that I can test later

[safinilnur]

Before I dig into the details, does that mean all the custom tags and filters in OC are not recognized? If yes, give some examples that I can test later

yes, all OC tags are not recognized. Only default fluid constructions are parsed by default.

The sample: if liquid contains an OC tag like {% style name:"Step-PersonalInfo", src:"~/GuidedFlow-Step-PersonalInfo.css" %} - the tool will silently fail for this liquid file. Translations from this file will be not exported. If we use this extension and define it in InlineBlocks - all tranlsations will be extracted properly.

In my custom project with 40 OC modules I accidentally notices some missing translations, which were caused by this. To solve the problem, I checked, which OC and custom tags were used (found only 6). So for a big project it will be easy to note the tags-related errors from the console and to add LiquidProcessorConfiguration file to fix them.

[safinilnur]

What I was thinking about - how OrchardCore created pot files for all their OC modules. As they had to fix also this problem, if they used poextractor without any modifications for that.

[hishamco]

So let's think about pros & cons for your proposal, coz pointing to an external file might be risky, @sebastienros, your thought

[safinilnur]

@MichaelPetrinolis FYI

[hishamco]

Logger instead?

[safinilnur]

@hishamco I'm not sure we shold use logger instead. I don't see the reason why we should do this. Also it will require changes in several files, so maybe, if we will do that, lets do in a separate PR then?

But I can do this, just, please, approve that we want to bring logger in this PR

[safinilnur]

I just mean that we don't use logger in the tool right now and the code which introduces a logger will mix with the changes I did (we will get ditry git commit history)

[hishamco]

Just waiting for Seb's feedback,

@Skrypt your input

[safinilnur]

@hishamco we have started to use this extension fix on our live environement, looking forward to complete and merge this fix here

[hishamco]

I will try to let someone bring this into the steering meeting

[hishamco]

Maybe it's related to OrchardCMS/OrchardCore#19394, so please hold on, I will check after the related issue is fixed

[hishamco]

@safinilnur, the related PR has been merged. I will update to OC 3. Please recheck, then let me know if the issue is fixed. Otherwise, we might consider this PR with some modifications until we fix the original issue

[hishamco]

Now you can use the nightly build to verify before we publish a new release