feature/enhance-pattern-matching

[alvinjohnsonso]

Added tawk.to pattern matching library and applied it to the module to have a more flexible URL/path rule filtering.

[alvinjohnsonso]

Hi @yorkshire-pudding, hope you're well. Just wanted to ask how would one structure a backdrop module that would contain external libraries managed by composer?

The way we did this to our other modules is that we created a github actions workflow to build the composer dependencies and package the module including the vendor folder.

[yorkshire-pudding]

Hi @alvinjohnsonso - There is some guidance on using libraries here - https://docs.backdropcms.org/documentation/using-libraries

In general, the approach is to have everything bundles inside the module folder. You would have a subfolder (libraries) and within that a folder for each library in use (e.g. tawk-url-utils ).

Does it need to be managed by composer? Making a dependency for a module to use composer is not encouraged as it raises barriers to collaboration. While lots of people have github actions running tests on PRs, I don't think we use composer.

Taking a step back, what is the need for this additional library? I've not have anything that I haven't been able to do with the existing pattern matching.

[alvinjohnsonso]

Hi @yorkshire-pudding I see. I'll probably just follow that guide you sent. Thanks for answering my question! 😁

As for why we're making this update, we've recently developed a library that provides more flexibility on doing url/path pattern matching to filter which pages to show/hide the widget from. We thought we could also use it on most of the plugins we're integrated to.

[alvinjohnsonso]

I made the vendor folder into libraries and didn't bother using the available library API that backdrop has. It seems that the API is only for loading css and js libraries into the module. So what I did was I just manually required the autoload.php that composer generated.

[alvinjohnsonso]

To anyone that might ask why these composer files are included is because Backdrop has its own release workflow that retrieves and builds the module when a release is published. I looked for other modules that has external libraries being used and they all included the library within their repository. Here are some of them:

• https://github.com/backdrop-contrib/colorbox
• https://github.com/backdrop-contrib/repeating_dates
• https://github.com/backdrop-contrib/leaflet

[yorkshire-pudding]

@alvinjohnsonso - I'm sorry but I can't see that this feature addition is required to the extent that we should increase the complexity in this way. The current pattern matching works well and I have never had any need for anything more complex to meet genuine use cases.

I'm not sure what you mean by "Backdrop has its own release workflow that retrieves and builds the module when a release is published". When Backdrop builds a module, it packages the zip, and tar.gz files and updates the .info file in the package zip file. I downloaded the file from your repo branch and was able to install using manual install from that.

I think there are too many examples in the tooltip. The config only requires paths from the root leading slash, so why have all the domains? I also don't think that a tooltip is good practice for guidance. I suggest to include in a collapsible section if necessary.

I'm afraid I cannot do a code review justice on such a massive increase in code.

[alvinjohnsonso]

Hi @yorkshire-pudding I understand. This was decided internally and I've asked my superiors to review it. Thanks for the inputs! 😁

[eug-L]

hi @yorkshire-pudding I'd like to pick up where my colleague left off

We have already released pattern matching to exclude pages from showing/hiding the widget on other platforms that we support. The significance of this feature is, it allows matching multiple pages with a single pattern with the use of wildcards, for example to exclude the widget from all posts one would use /posts/* or to exclude pages that ends with "contact" they can use */contact. This works on top of existing full url/slug patterns so it will not break existing configurations.

For the usage of composer, I will remove the dependency of composer as an autoloader, but would like to keep composer.json for the convenience of downloading updates for our library. Since we do not release updates very often, this should not impact collaboration efforts in terms of requiring composer to fetch an update.

[yorkshire-pudding]

Closing in favour of #12