datakick

It's on a hold right now, as I don't have free capacity to work on it. Still I'd like to finish this

Just to be sure - did you set this module to be your mail transport? If so, you could try to misconfigure it (set wrong password) - to verify that it actually communicate with your smtp server.

Not possible. Each country can be only in one zone. Entire system expects this behaviour.

Back to the original question: No, it's not possible to use the attachments without file. You could change the template code and hide the file attachment input, but that is not enough. The backend would not process the add/edit request -- it expects file, and it does a lot of work processing it. If you really want to (ab)use this attachment functionality, you could simply upload some small/dummy file. And then you can modify your front theme product template, and not displaying any attached files.

That will be some 'security' measure installed on your server - firewall, antivirus, or something similar that blocks your server from downloading zip file. Or maybe write permissions for /modules/ directory

https://github.com/thirtybees/thirtybees/issues/1759 Cache problems. Try updating to bleeding edge

I'm sure there are many. My datakick module can be used to generate xml feed for GMC. You can use channable module to export your content to channable, and from there you can push it to any number of third party services, including GMC. there is google shopping flux free module (https://github.com/d1m007/gshoppingflux) - there is some compatbility issue with thirty bees, see this PR: https://github.com/d1m007/gshoppingflux/pull/105/files and I'm sure there are many more

I'm afraid that would not work properly with watermark module.

Please file a github issue, with sample CSV files. Describe expected and actual results.

Use sitemap module, and configure it to use proper image variants: Add your sitemap to your google console, and wait for google to reindex.

Oh, sorry about that, that was a bug in installation zip file. Please uninstall the module, and then delete the module from your disk. After deletion, install it again. It will download the new, fixed package

Also, before installation, ensure that your PHP has following extensions installed / enabled: Required: bcmath gd json mbstring openssl mysql (PDO only) xml (SimpleXML, DOMDocument) zip Recommended: imap (for allowing to use an IMAP server rather than PHP's built-in mail function) curl (for better handling of background HTTPS requests) opcache (not mandatory because some hosters turn this off in favor of other caching mechanisms) apcu/redis/memcache(d)

I remember that some old version of thirty bees had issues when they encoutenr system compatibility problem during installation. Instead of displaying error message it displayed just blank error page. Try use 1.5.1 installation package instead.

Oh yeah, it's funny. And sad. Mostly sad. Not funny at all, actually. You can try it yourself (on a testing environment, please). For example, view any order, and change vieworder in url bar to deleteorder https://domain.com/admin-dev/index.php?controller=AdminOrders&id_order=3&vieworder&token=<token> https://domain.com/admin-dev/index.php?controller=AdminOrders&id_order=3&deleteorder&token=<token> And hit enter. Order is deleted. This is how Delete button in list works now. It is simple GET request, guarded by confirmation popup. But when prefetching is enabled, the browser calls this GET url before you hit confirm. This particular problem can be fixed by fixing HelperList, and sending post ajax request instead. That would, probably, break a lot things, integration with third party modules, etc. You know, backwards compatiblity.

It can't be empty. Just put in some placeholder text like "New order created" and thats it

Ok, so that's the problem. Module checks that both email template variants exists. It shouldn't really do that, I'll create a ticket for that.

what about new_order.txt template?

Did you check content of the template? Maybe the template is empty (there was a bug in older version of thirty bees that generated empty template files sometimes) Is swedish the only lang in the store? If not, make sure the template exists for all languages - mailalert will use language that is assigned to employee preferences, so if the employee is using english for back office, the en variant of email template is used for them.

My guess is that email template 'new_order' is not translated for the employee language (or for shop default language)

Yes, of course. caching -- cloudflare is a great CDN network that can cache your static assets (images, css, js, video,...) and deliver it very fast. This can take a lot of stress off your server, freeing resources for PHP and DB processes. So even cheaper server can handle a lot requests world-wide -- since cloudflare has many data centers all over the world, the (cached) content is delivered fast everywhere. If you sell world-wide, this can be quite difference -- visitors from Australia can access your server located in Frankfurt almost as fast as visitors from Munich. security -- cloudflare has nice security features that you can enable/disable at will -- quite useful during attacks on your server free SSL without any hassle -- I know you can easily generate Let's Encrypt SSL certificates, but even that sometimes fails and admin has to attend to it. With cloudflare it's completely without any problems IP address privacy -- I like the fact that you can hide your server IP address from outside world geolocation for free -- cloudflare sends geolocation https headers that you can use to determine country of your visitors. You can do the same with maxmind geoip module, but then you need to keep the IP database up-to-date. With cloudflare, you have that accurate and for free. Here's my module that can utilize this information: https://store.getdatakick.com/en/modules/cloudflare-geoip Yeah, that's true. I made a module to automatically purge cloudflare cache when you clean thirty bees cache, so that helps: https://store.getdatakick.com/en/modules/cloudflare-cache-purger

I've checked the SSL certificate for your mail server: openssl s_client -connect mail.jv80.se:587 -starttls smtp -crlf outputs Connecting to 156.67.80.139 CONNECTED(00000005) depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1 verify return:1 depth=1 C=US, O=Let's Encrypt, CN=R11 verify return:1 depth=0 CN=mail.mxmail.pro verify return:1 --- Certificate chain 0 s:CN=mail.mxmail.pro i:C=US, O=Let's Encrypt, CN=R11 a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Oct 7 10:04:49 2024 GMT; NotAfter: Jan 5 10:04:48 2025 GMT 1 s:C=US, O=Let's Encrypt, CN=R11 i:C=US, O=Internet Security Research Group, CN=ISRG Root X1 a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Mar 13 00:00:00 2024 GMT; NotAfter: Mar 12 23:59:59 2027 GMT --- Server certificate -----BEGIN CERTIFICATE----- MIIFUjCCBDqgAwIBAgISA3dwbr6Y61zugeXx1GxKELtmMA0GCSqGSIb3DQEBCwUA MDMxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQwwCgYDVQQD EwNSMTEwHhcNMjQxMDA3MTAwNDQ5WhcNMjUwMTA1MTAwNDQ4WjAaMRgwFgYDVQQD Ew9tYWlsLm14bWFpbC5wcm8wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCSQ1HbHGiBbou7GOZhL0jYk2D3IK3Al48pX/OioRQJL57c0HFCFRGrJgJ523qQ gt9yHwmeSjr+JdsAedOw0evb2rKf3CaKfW7ECMkW0cUvM8yhOs2LyC8o+DLhhFGQ gh1VsfOetKN05zM11vLfqWpuRsLa7nqJTE1ZIxYLpe1pG1zVY2N36FqVdw06ptOw UxTxDzhdi5BbAsdjC8rVweo0Ja0pTUb9F+nmQV5F1U0g/eLsyjzQvyhFVhJdc1sH 8YlDTw9NnSPm84GUlT/Gxzo3u7tMPYRh4KSE6i+uYUm21phRDZeUzzzYFGY4nfX1 SoP/9Qqjg51T2xuv0Dgg5MpLAgMBAAGjggJ3MIICczAOBgNVHQ8BAf8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMAwGA1UdEwEB/wQCMAAwHQYD VR0OBBYEFDk9g01mxaxjoVTkhDGc59225HJQMB8GA1UdIwQYMBaAFMXPRqTq9MPA emyVxC2wXpIvJuO5MFcGCCsGAQUFBwEBBEswSTAiBggrBgEFBQcwAYYWaHR0cDov L3IxMS5vLmxlbmNyLm9yZzAjBggrBgEFBQcwAoYXaHR0cDovL3IxMS5pLmxlbmNy Lm9yZy8wfQYDVR0RBHYwdIIMbWFpbC5qdjgwLnNlghxtYWlsLmt0aW1hdGhlb3Bo YW5vdXMuY29tLmN5ghJtYWlsLm1lZGlhc2FmZS5wcm+CD21haWwubXhtYWlsLnBy b4IObWFpbC5teG1haWwuc2WCEW1haWwucGlzc291cmkub3JnMBMGA1UdIAQMMAow CAYGZ4EMAQIBMIIBBQYKKwYBBAHWeQIEAgSB9gSB8wDxAHcAzxFW7tUufK/zh1vZ aS6b6RpxZ0qwF+ysAdJbd87MOwgAAAGSZqXgAAAABAMASDBGAiEAiQZplHsW+AXR C5g1d1yuPRiPiIGACuOZn8ZBgQPB7z0CIQCwTvKO+VMaeOq8rRXaNiLdiqKlz7lk RH704XdJjJWIAgB2AD8XS0/XIkdYlB1lHIS+DRLtkDd/H4Vq68G/KIXs+GRuAAAB kmal54wAAAQDAEcwRQIgZqd3CmlCk+h6p8HfSW+SzmlfgwyENhHl4JbqdPZvKboC IQDJ762uDxba1ZT2GibDQn87EO/TVJaQh2uol0i9FG+NpjANBgkqhkiG9w0BAQsF AAOCAQEAVHukoNoGdJwB6urbDbq0tzCoK1RfdQK/IjZoiGPK6IiQS6SQH8tG8g+X HhFfsnSdpPLK4UHB/e1KnGD0YuHXrYhBSsF4wSsq4bwNp6o+123P8fIblEVZStZG Wyfhj/mpmpN86LPs7sJRSrZREmU2txdSx0F930AgDrPZ3sdTYuEs4SQnyymdRcbo P+iERwxCnOX5SFuEEYWW75WSOWGIY34L8py+mFLdy+C/l4rv/yXNLOT9HuT+FbP5 1/VewuSEp/gCDTxQT9PqgwGDuX7KWcp77iho6zqgNyPyW1SU3qhvfpg0AeT1XHU5 iAcmR7M8XMqDOpv+4p5XhY//5gREqQ== -----END CERTIFICATE----- subject=CN=mail.mxmail.pro issuer=C=US, O=Let's Encrypt, CN=R11 --- No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits --- SSL handshake has read 3408 bytes and written 433 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 2048 bit This TLS version forbids renegotiation. Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- 250 DSN DONE The SSL certificate was issued primarily for domain mail.mxmail.pro and not for mail.jv80.se However, when you decode certificate (for example by https://www.sslshopper.com/certificate-decoder.html), you will see that the certificate CAN be used by mail.jv80.se, because this domain is listed in Subject Alternative Names section. So, the SSL handshake should be successful. Hower, it looks like php native SSL method does check SAN when verifying peer name -- it expects peer CN to match the requested hostname, and does not check SAN list as well. Fortunately, it might be possible to force PHP to accept SAN if your provide the peer name in SSL options, as described here: https://github.com/PHPMailer/PHPMailer/issues/1113 You can test this by editing file /modules/tbphpmailer/src/PhpMailerTransport.php and insert this code. $message->SMTPOptions = [ 'ssl' => [ 'peer_name' => 'mail.jv80.se' ] ]; Result should look something like this: Let us know if this helped.

That is not an application issue, but server issue. Check this: https://github.com/PHPMailer/PHPMailer/wiki/Troubleshooting#certificate-verification-failure Most likely, your hosting providet is redirection all smtp traffic to their own smtp server.

Yes, that's the one. Deactivate this It would work nicely on websites that follow REST principles, and don't have side effects on GET requests. But on sites that perform side effects on GET requests, it's very dangerous. It's stupid that in thirty bees you can 'delete' a record by simply writing url into url address tab and hit enter.

Hi everyone, I just wanted to raise your attention to the fact that cloudflare recently enabled Speculation Rules API for all plans. This functionality is designed to improve browsing speed by aggressively prefetching potential future assets/pages etc. However, these prefetch requests can be quite dangerous sometimes. Example: I'm in back office modules pages, and I click on 'Uninstall module' button. The confirmation dialog is displayed to ask if I'm sure. But the question is irrelevant - because of this new prefetch functionality, your browser already sent a request to your server to prefetch the response for the uninstall action url. The module is already uninstalled You can see the request in network tab. Even though claudflare responded with 503 error code (meaning the prefetch response will be ignored by browser), the request still made it to your server, and action was executed. If you click 'OK', thirty bees will send the actual request, and it will actually fails with error message "This module has already been uninstalled" That's nice, isn't it. The uninstall/install module buttons are not the only one that are impacted. For example, 'delete' or 'approve' or 'send' buttons in lists in back office, etc... It can also impact front office, most likely -- browser can automatically add product to a cart because it believes that user will click on the "Add to cart" button soon, so better be prepared for that... right. It's quite dangerous optimization. It's true that if thirty bees used POST instead of GET requests to implement these kind of actions, this situation could not happen. But we can't really change that. We will look into a way to prevent/mitigate this problem. Fortunately, browser is sending some HTTP headers that we can use to determine if request is a regular or prefetch, so we can use that to prevent this (hopefully) But until a fix is implemented, I advice you to disable this new prefetch optimization in your cloudflare dashboard. And to be sure, maybe even after that 🙂

There is no change. Neither thirty bees, nor prestashop, sends email notifications about new orders to merchants by default. This functionality is provided by mailalert module.