Email sent has incorrect product URL


#1

This appears to be a bug in applications/shop/webapp/shop/order/orderitems.ftl

This line:
<a href="<@ofbizCatalogAltUrl productId=origProductId/>" class="${styles.link_nav_info_desc!}" target="_blank"><#t/>

When a user performs an order checkout, and clicks “Submit Order”, the “Thank you for your order!” page looks proper, and HAS the correct URL for the products purchased.

i.e. https://domain.com/en/gallery/product/10000/10001/10002/10000-798936836182

When the email is sent out, the corresponding email has an improper URL: The above link will show up in the email as:

https://localhost:8443/en/gallery/product/10000/10001/10002/10000-798936836182

The “localhost:883” should be “domain.com”.

Which is quite worthless for an email.

I have tried setting all the properties, but it seems to make no difference.

What appears to happen is the series of events that generates the order “Thank you for your order!” page is replicated again when email notifications are enabled, but something is different, and the above line resolves the domain incorrectly when the email is generated. I understand that the submitting of the email is a separate “Send Email” job that, when run, does not quite have all the information needed to correctly render the email.

The demo does not have email notifications enabled, so I suspect this is why this bug has remained hidden for so long.

Thanks!


#2

Hey Mike, happy 2019

There were fixes to email URLs in the master branch fairly recently. If you’re on master branch you can try pulling using git. If you’re on 1.14.3 (sorry I can’t remember) they’ll appear in next release soon.

Or if you already pulled there could be another issue.

Did you configure the domain using url.properties or on the WebSite entry? (Temporarily as a workaround, url.properties may be needed for some emails)

FYI: made small formatting edit to your post.


#3

Also, after updating, check the log for Warning entries. During the email render, if it cant find a domain for the email there will be a warning.


#4

I guess I should have mentioned, yes, I’m on dev branch (1.4.4), and I performed a new update, and the problem still exists. New info, this issue is present in two FTLs, the emailHeader.ftl and orderitems.ftl, as shown below.

Did you configure the domain using url.properties or on the WebSite entry? (Temporarily as a workaround, url.properties may be needed for some emails)

Can you provide an example of these? I looked in url.properties and nothing was obvious. I did try to adjust
items in url.properties:

force.https.host=
force.http.host=
content.url.prefix.secure=
content.url.prefix.standard=

I tried all of the above and they either didn’t make any difference or greatly messed up the website. I also looked at general.properties and saw this obscure note:

– The default domainname used in the notification emails links as ‘baseUrl’ and ‘baseSecureUrl’ are set in the url.properties file.

Which isn’t true (they are not in url.properties), but seem to be in content.properties:

baseUrl=
baseSecureUrl=

Tried setting the above but to no avail.

I also went in the UI under Website (under Store), and set:

Standard Content Prefix=http://example.com
Secure Content Prefix=https://example.com

Also, no change. It’s just the sending of the email when this occurs. The below is an log excerpt that shows that the issue occurs in two different FTLs:

root@kvm01:/opt/scipio-erp/runtime/logs# egrep '(\|W\||Template component|localhost)' log
DEBUG SMTP: trying to connect to host "localhost", port 25, isSSL false
DEBUG SMTP: connected to host "localhost", port: 25
 <!-- Begin Template component://common/webcommon/includes/email/openEmailBody.ftl -->
<!-- End Template component://common/webcommon/includes/email/openEmailBody.ftl -->
<!-- Begin Template component://common/webcommon/includes/email/ -->
                    <img src="https://localhost:8443/images/scipio/scipio-logo.svg" class="scipio-image" style="width: 200; height: 50;object-fit: cover;"/>
                        <th><!-- End Template component://common/webcommon/includes/email/emailHeader.ftl -->
<!-- Begin Template component://shop/templates/email/OrderNoticeEmail.ftl -->
<!-- Begin Template component://shop/webapp/shop/order/orderheader.ftl -->
<!-- End Template component://shop/webapp/shop/order/orderheader.ftl -->
<!-- Begin Template component://shop/webapp/shop/order/orderitems.ftl -->
  <td><a href="https://localhost:8443/en/gallery/product/10000/10001/10008/10000-625904520203" class="link-type-text action-nav action-secondary" target="_blank">10000-625904520203 - AGATHA CHRISTIE&#x3a; MURDER - ORIENT EXPRESS</a>
<!-- End Template component://shop/webapp/shop/order/orderitems.ftl -->
<!-- End Template component://shop/templates/email/OrderNoticeEmail.ftl -->
<!-- Begin Template component://common/webcommon/includes/email/emailFooter.ftl -->
</table><!-- End Template component://common/webcommon/includes/email/emailFooter.ftl -->
<!-- Begin Template component://common/webcommon/includes/email/closeEmailBody.ftl -->
</html><!-- End Template component://common/webcommon/includes/email/closeEmailBody.ftl -->
2019-01-03 12:42:19,766 |andardHost[0.0.0.0]] |ControlEventListener          |W| Could not find visit value object in session [hidden] that is being destroyed

#5

Previous post obscures:

<!-- Begin Template component://common/webcommon/includes/email/emailHeader.ftl -->
<img src="https://localhost:8443/images/scipio/scipio-logo.svg" class="scipio-image" style="width: 200; height: 50;object-fit: cover;"/>

#6

There are 2 types of links, control/navigation links (including the product/catalog URL) and content/image links. They can (often must) each get their own prefix.

You have to restart the server for properties to take effect.

Navigation links: On our server for example url.properties is configured like this:

port.https.enabled=Y
port.https=443
force.https.host=ce.scipioerp.com

# HTTP Port (Not Secure port)
port.http=80
force.http.host=ce.scipioerp.com

The content links are determined by:

content.url.prefix.secure=https://something.com
content.url.prefix.standard=http://something.com

The one in content.properties (“baseUrl”) is a relic, today it is only used if url.properties or WebSite aren’t configured.

Just to narrow things down, I would recommend going to the catalog store website list and make sure your WebSite is set as the default (depends on how you set this all up in the first place), substitute your store ID in this link: https://localhost:8443/catalog/control/EditProductStoreWebSites?productStoreId=ScipioShop (click “Set Default” on the right in the website list).

Note that anything entered for WebSite host/port is designed to override url.properties (maybe stick to url.properties to debug this issue, unless you’re relying on it already). WebSite has a bunch of entries equivalent to the ones in url.properties.

I will check some things but that’s the basics for now


#7

The link in your last post (scipio-logo.svg) is actually a specific bug with that specific link (it doesn’t reflect the configuration), it still uses the old (poor) link building code, thanks for pointing it out. However, the others shouldn’t suffer from this and should pull from WebSite or url.properties.

(That one is a bug I will fix, however it is the only place I see a bug at this time, the rest is probably configuration issue as it works on other server)


#8

This fixed it!!! But there were some oddities. The trick to fixing this (for ME) was by setting:

port.https.enabled=Y
port.https=
force.https.host=example.com

HTTP Port (Not Secure port)
port.http=8080
force.http.host=example.com

First off, I use Apache/AJP exclusively, so I couldn’t use port 443/80, because apache uses them.

Also, a large part of my issues was a misunderstanding of what “force.https.host” was supposed to be set to… Initially, I used “https://example.com”, and thanks to your example stripping out the “https://” made this actually work.

If I set “port.https=8443”, the emails showed up as “https://example.com:8443/…”, so blanking out the https port fixed this. Naturally, I tried blanking out “port.http”, but oddly this freaked out solr, and it wouldn’t start, but I found that by setting this to 8080, this satisfied solr (not sure why).

But, thanks for the tips! Been working on this days.


#9

Ok great. I will fix that one link that is actually a bug, so thanks for reporting regardless.


#10

NOTE: You will also probably have to set content.url.prefix.secure as well or risk running into another issue soon (that one needs to have the https:// prefix). The bad scipio-logo.svg link is confusing and probably makes it seem like it’s not needed, but it actually is.

(The whole baseUrl/baseSecureUrl thing in emails was a design error in the old code and creates all this confusion)


#11

Just to point out, I agree the url.properties format is inconsistent (some take http:// while others don’t) so I understand your confusion, it’s only that way for historical reasons (like the baseUrl/baseSecureUrl thing, that we’re getting rid of, because it never took into account control vs content URLs so it was just plain wrong all along).


#12

Thanks… It would be useful if these were set with working examples, or maybe a comment. By the way, having issues getting paypal_rest to work. Another ticket soon. [grin]