Fix for ratings not displayed when using custom templates

If this add-on is not displaying the ratings, and you're using custom templates, I found the solution.

In product_reviews.xml, there are 2 lines that need to be changed:

change this line
<file name="includes/templates/default.catalog/views/box_product.inc.php">
to
<file name="includes/templates/*.catalog/views/box_product.inc.php">
and change this line
<file name="includes/templates/default.catalog/views/listing_product.inc.php">
to
<file name="includes/templates/*.catalog/views/listing_product.inc.php">

Your ratings will now be displayed properly.

I used to do wildcard "*.catalog" but changed it to "default.catalog" as wildcard will most likely breaks due to the fact we have no clue how a custom template is made.

You lost me.  What does the wildcard have to do with how a template is made?  Isn't it simply for the path?

Is this something new for 2.5.x?

The asterisk is a wildcard for folder matching that is by the POSIX glob pattern standard.

*.catalog matches template1.catalog, template2.catalog, template3.catalog, template4.catalog.

Now those are not distributed by LiteCart. Only the default template is.

So how do we know that these custom templates matches our modification directives? We don't. In fact we should take for granted that they are different, otherwise the merchants would just have used the default template. If they adjust the rule to match their specific template content it will instead break with the default files. So I find it good practice to add custom modification directives for custom templates.

This actually makes total sense.  : )

Using default.catalog is just not working for me.  The reviews box doesn't show up on my custom product page.  However, using *.catalog works just fine.

How is using default.catalog supposed to work?  Maybe I have another problem that's preventing it from working for me.

When you have a custom template, make sure there is vmod directive that conforms with your template. In this case you need a directive to include box_product_reviews.inc.php on views/box_product.inc.php. The login in box_product_reviews will first look for a view in your custom template folder, then fallback to a view in the default template folder if one isn't found.

[quote]When you have a custom template, make sure there is vmod directive that conforms with your template.[/quote]
Are you saying we have to hard-code our custom template names into vmods now?

Would you give an actual example?

<file name="includes/templates/default.catalog/views/box_product.inc.php">
does not find my custom template.

However
<file name="includes/templates/*.catalog/views/box_product.inc.php">
does.

LiteCart 2.5.3

I have tried "*.catalog" and received complaints that the vMods are broken with their custom templates. Of course they break, custom templates are custom made. I cannot foresee the code in the files mathing the pattern.

So to prove that the mod itself is not broken I then changed the path to "default.catalog". I have then received complaints that mods are broken because it doesn't do their custom templates but shows no errors.

How would you solve this?

Here goes an example

This directive would match all frontend templates stored that have a file views/box_product.inc.php:
<file name="includes/templates/*.catalog/views/box_product.inc.php">

The real problem is not the path but the operations. Each operation needs to match a particular line of code. You are assuming that we should match lines in your custom template. The problem is that it probably contains custom stuff. How do we match your custom stuff? We can't. So what is then the expected behaviour of a vMod what comes to foreseeing code in custom termplates?

Just so I know, are you saying that we should hard-code our custom path in the vmods now?

I'm asking what other choices we have? How would you do it?

If you're saying that we would need to hard-code our custom directories into vmods now, I'll have to disagree with that.  As you know, hard-coding data should be avoided whenever possible and, after thinking about it, this is one of those times.  Making this change will adversely affect more people than allowing us to use a wildcard does.

If someone rewrites their templates so much that it breaks the add-on, then yes, they'll have to hard-code their custom path, but I don't think that everyone should be made to do that simply because of those few.  I've been using LiteCart since 2019 now and I've [i]never[/i] run into that problem.  And if I did, I'd expect to have to hard-code that path.  But, under normal circumstances, we shouldn't have to.

Please bring back the wildcard feature.  Place a disclaimer in the Read Me of every add-on, and in the wiki, and you'll be covered.  You're not responsible for every boned-headed move people do with your code.  : )

Just to be clear, I'm not suggesting that you start using wildcards in vMods again.  I simply hope that you don't remove the wildcard feature for us to use in our own vMods.

There are no plans to remove glob pattern support in path names. You can continue do globstars.

+1

Phew!  You had me worried there!  : )