dynambee

A very minor issue but the Back Office Bug Tracker Link that is shown in the footer of all Back Office pages is invalid. I assume this is because the new forum didn't maintain URL compatibility with the old forum, but it's still a small issue that needs to be fixed. Found on 1.0.8 with all Bleeding Edge core updates applied.

SUMMARY I think I can summarize this with a few points: I was not able to completely replicate my results from yesterday. I am not sure exactly why this is but I did get "Free Shipping!" shown in more than one way yesterday, and I took the screenshots shown in the first comment. Even though "Free Shipping!" isn't always displayed there are still problems with how the shopping cart handles out-of-range shipping before the checkout process begins. The results are sometimes different depending on if a user is logged in or if there is no user logged in. Besides just the "Free Shipping!" display issue sometimes no shipping costs at all are displayed or the maximum weight range value is displayed, even though no shipping is available. When no shipping is available the cart should display a message about this to the customer. Something as simple as "No shipping available" would be fine. The checkout process itself (step 4 where the shipping carrier is chosen) does work fine so this isn't an issue where people can choose carriers that they should not be able to choose. Instead this is an issue where incorrect information (or no information) is shown to customers before they start the full checkout process. I did not run all of today's tests on PS 1.6.1.24 but as best I can tell it does operate in the same way. Therefore this is likely a problem that was inherited from the PS code.

CART ACTIONS WITH USER LOGGED IN Test 1: Add one item to cart Pop-up shows "Total products" price correctly Pop-up shows "Total shipping" price correctly Pop-up shows "Total" correctly with the correct amount of shipping added. Click "Proceed to checkout" "Shopping-cart summary" page is displayed Total shipping is correctly shown as $4 Test 2: Add 50 items to cart This exceeds the maximum weight limit of all available carriers Pop-up shows "Total products" price correctly Pop-up shows "Total shipping" as "Free shipping!" Pop-up shows "Total" price with no shipping costs applied. Click "Proceed to checkout" "Shopping-cart summary" page is displayed "Total products" price is correct Nothing is mentioned at all about shipping "Total" is shown with no shipping costs applied Test 3: Add 20 items to cart This does NOT exceed the maximum weight limit of all carriers Pop-up shows "Total products" price correctly Pop-up shows "Total shipping" price correctly Pop-up shows "Total" correctly with the correct amount of shipping added. Click "Proceed to checkout" "Shopping-cart summary" page is displayed Total shipping is correctly shown as $68.18 Use the Quantity increase button [+] to increase the quantity from 20 to 120, one item at a time 40 items would exceed the maximum weight limit of all carriers The "Total shipping" row never changes, it remains at $68.18 even though this is impossible because no carriers are available

TESTS RUN WITH NO USER LOGGED IN Test 1: Add one item to cart Pop-up shows "Total products" price correctly Pop-up shows nothing at all about shipping BUT the correct amount of $4 shipping is applied Pop-up shows "Total" price correctly (correct amount of shipping is applied) Click "Proceed to checkout" "Shopping-cart summary" page is displayed "Total shipping" is correctly shown as $4 Test 2: Add 50 items to cart This exceeds the maximum weight limit of all available carriers Pop-up shows "Total products" price correctly Pop-up shows nothing at all about shipping AND no shipping costs are applied Pop-up shows "Total" price with no shipping costs applied. Click "Proceed to checkout" "Shopping-cart summary" page is displayed Nothing at all is displayed about shipping, the shipping costs line is not visible Test 3: Add 20 items to cart This does NOT exceed the maximum weight limit of all carriers Pop-up shows "Total products" price correctly Pop-up shows nothing at all about shipping BUT the correct amount of $68.18 shipping is applied Pop-up shows "Total" price correctly (correct amount of shipping is applied) Click "Proceed to checkout" "Shopping-cart summary" page is displayed "Total shipping" is correctly shown as $68.18 Use the Quantity increase button [+] to increase the quantity from 20 to 40, one item at a time 40 items would exceed the maximum weight limit of all carriers When 40 items is reached the "Total shipping" line disappears completely Once the "Total shipping" line disappears the overall "Total" line no longer includes any shipping charges

I have just spent a bunch of time running tests in a more controlled fashion to get hopefully clearer results about what is going on. Before proceeding, it is important to note that on page 4 of the multi-page checkout where the customer would normally choose the shipping type the system does correctly display that no carrier is available if in fact no carrier is available. The problem is not here, the problem is that when viewing the contents of the shopping cart (either in a pop-up or in the pre-checkout stage) incorrect information or no information is sometimes displayed. Here is how I set up the system for my tests: Back Office Notes: All non-tb modules disabled All overrides disabled All server caching disabled No CDN in use Front Office Notes: Each and every test was run in a freshly opened incognito mode browser to make sure no local cache exists All tests run with Chrome 75.03770.80 64-bit on Win10. Everything updated as of yesterday. Carrier Notes: System has three carriers available, two with shipping rates set for up to 2kg and one with shipping rates set for up to 10kg Each test was run twice. The first set of tests were run with NO maximum values for the carrier width/height/depth or weight set The second set of tests were run WITH maximum values set for the carrier width/height/depth and weight set. For the second set of tests (WITH maximum values set) the weights were set to be the same as the maximum weight range of each carrier in question. Therefore for the two carriers with rates set for up to 2kg the maximum weight was set to 2kg. For the third carrier with rates set up to 10kg the maximum weight was set to 10kg. The results of the tests were the same regardless of if maximum carrier width/height/depth/weight were set so it does not seem that this setting is the cause of the problem. I am only showing one set of results for each test run because the results were identical The cart behaved differently depending on if a user was logged in or if no user was logged in (guest). Therefore I will now create two more comments, one showing the results for when a user was logged in and another for when no user was logged in.

The checkout process works okay, in step 4 of the checkout a "no carrier available" message will be displayed. The problem is what is displayed in the cart before the checkout itself is started. I have run a bunch more tests in a more controlled way and will be posting results shortly.

@t4Chippy how is this going? Did you get it to work? What was the problem?

(I reported this on GitHub but figured I'd put a report here too in case someone else comes across this problem and is searching the forums.) This problem exists on TB 1.0.8 (default install) and after the Core Updater does the full "Bleeding Edge" update. It also exists in PS 1.6.1.24. If you add enough items to the cart that the total combined weight exceeds the maximum weight of all the available carriers the cart will show "Free Shipping!" instead of "No Shipping Available": The same thing will happen on the "Shopping-cart Summary" page, the first page of the checkout process, if an item's quantity is increased to the point that the total combined weight exceeds the maximum weight of all available shipping carriers: Once the checkout process continues and reaches step 4 the user is finally told that no shipping carrier is available because the maximum weight of all available carriers has been exceeded: When viewing the shopping cart it should not say "Free Shipping!" when in fact there are no carriers available. It should either show nothing at all about shipping or (better) it should say "No Carrier Available", "Shipping Not Available" or a similar message. Note: The default sample products from TB do not have any weights assigned to them so this problem is not immediately visible on a test install.

Unfortunately there are some APO/FPO locations that Japan Post does not ship to. I do not know why this is but I also cannot change it. I have seen some discussion about how to do this manually with a class override, though I am not sure how well the sample code would work with TB. I could probably adapt it though, if necessary. (I would create a separate zone, assign that zone to no carriers, and then return that zone's ID if the zip code matched the ones I can't ship to.) There is also this this promising looking module that seems to be compatible with PS 1.6 so may also work with TB 1.0.x. My questions: How bad would it be to use an override to do this? Is there any other way to block APO/FPO from shipping? What is the likelihood (roughly speaking) that the module I linked to would be compatible with TB 1.0.8 "Bleeding Edge"? Thank very much for any thoughts, ideas, or help.

The quality of the blog posts has to be excellent or it reflects poorly on the project. With this in mind it takes hours to write them, edit them, proof them, and finally get them online. With the limited human resources of the project right now (and the project not being profitable yet) it would seem to me that those hours could be better spent doing other work.

Here is some sample PHP code that you should be able to use to send a test message. You (or your friend) will need to customize it with the directory path to the swift_required.php file as well as put the right to/from email addresses in and the correct password. This will create a TLS connection to your server and send the message. Looking at the swiftmailer code it would seem (as best I can tell) that if TLS is specified that it tries STARTTLS first. I am no PHP guru though and the swiftmailer code is beyond my abilities. Put the sample code in a PHP file on your server somewhere you the webserver can see it, and make sure the permissions are correctly set. Then you can access it from a browser to run the PHP and send the mail. If you put it in the root directory and name the file test_tls.php you would need to do something like this to run the file: http://mydomain.com/test_tls.php Here is the code: <?php // If you don't get the path right the webserver will give you an error and from the error you should be able to deduce the correct path: require_once '[you will need to put the full path here so that the webserver can find the file] /vendor/swiftmailer/swiftmailer/lib/swift_required.php'; // Create the Transport $transport = (new Swift_SmtpTransport('smtp.office365.com', 587, 'tls')) ->setUsername('your-username-here-its-probably-your-email-address') ->setPassword('your-password-here') ; // Create the Mailer using your created Transport $mailer = new Swift_Mailer($transport); // Create a message $message = (new Swift_Message('TLS Test Email')) ->setFrom(['[email protected]' => 'Your Name Here']) ->setTo(['[email protected]' => 'Send To Name']) ->setBody('Here is the message itself. This is a test of the TLS system.') ; // Send the message, display errors: if (!$mailer->send($message, $errors)) { echo "Error:"; print_r($errors); } ?>

This is interesting, your server may not support TLS connections. What host are you using? Did you do the openssl tests that I asked about before? What were the results?

Customers don't like to be asked their date of birth during the account creation process but TB does not provide an easy way to hide this request. Thankfully it can easily be hidden with a little custom CSS. The following lines need to be added to the "Add extra css to your pages" section in the "Preferences/Custom Code" area of your TB back office: /* For desktop browser account creation, add this line: */ .account_creation .date-select { display: none; } /* For mobile browser account creation add this line: */ #opc_account_form .date-select { display: none; } /* For the user's "My account" page that they can see after they sign up, add this line: */ #identity .std .date-select { display: none; } The commented lines (/* ... */) do not need to be added, only the CSS lines that start with . or #. Copy & paste to avoid errors. I have tested the above on TB 1.0.8 with the standard community theme (obviously) and it is working without trouble. It may work with other themes as well but test before deploying. Thanks to @Brent Dacus for suggesting to put this CSS in the Custom Code area instead of modifying the template's global.css file directly.

Sure, I'll make a post there now. Edit: The post is here:

That seems to work too, better way to do it for sure. Will edit the previous post.

Okay, I have actually worked out how to hide it in all three places that it appears. The following lines need to be added to the Add extra css to your pages section in the Preferences/Custom Code area of your TB back office: /* For desktop browser account creation, add this line: */ .account_creation .date-select { display: none; } /* For mobile browser account creation add this line: */ #opc_account_form .date-select { display: none; } /* For the user's "My account" page that they can see after they sign up, add this line: */ #identity .std .date-select { display: none; } The commented lines (/* ... */) do not need to be added, only the code lines that start with . or #. Copy & paste to avoid errors. I have tested the above on TB 1.0.8 with the standard community theme (obviously) and it is working without trouble.

It definitely works. It removes it from the account creation page, but it leaves it visible in the "My account" area. If someone *really* wants to give their DOB they can still do it, but they can also completely ignore it which most users will likely do. The big thing is that they aren't asked for their DOB when creating an account. Of course as with any theme file edits, they will be lost if/when the theme is updated. I keep a separate record in a local text file of any changes I make so I can redo them after doing an update.

You can add it to the bottom of the global.css file which is located in /themes/community-theme-default/css I just tested it with TB 1.0.8 and adding the single CSS line to the bottom of the file caused the DOB request to vanish from the account creation page.

That's definitely odd as it doesn't work at all for me. Maybe it's related to mailcow, I can try it with gmail at some point. I also tried mailinabox but I found it restrictive and very lacking in features. That's pretty much the point of mailinabox (simple system with little to go wrong) but it just wasn't for me. I tried a few others as well but settled on mailcow as being the best balance between features, support, and updates. It works well. I'd actually like to migrate to OpenSRS but they do not offer any sort of push mail (no IMAP idle) so I'm still self-hosting for now.

Can you connect to any other mail server using TLS on port 587?

I have been playing with the mail settings on my development tb 1.0.8 server and have noticed a couple of things. First is that both SSL and TLS are working on my server. I do not have any Office 365 accounts so I can not test if connectivity there is working or not, but I can say that against my mailcow server I can connect both ways. SSL on 465 or TLS on 587. TLS is faster by quite a bit but I am not sure why. In any case TB itself seems fine with both SSL an TLS connections. Second, the "Send a test mail" button in the back office does NOT seem to work at all, at least not when SMTP is set up. Even when the "Contact us" form can successfully send emails the back office Advanced Parameters/Email "Send a test mail" fails. @lesley is this a known bug? Third, when you change the settings for the email server and then click save it seems to save an invalid password over whatever password you had there previously. You must paste your password into the password field each time you change the SMTP settings and save them. Perhaps with this information you will be able to get things working.

Each DNS entry has a TTL (time to live) setting. If a server has queried your SPF record it may cache it until the TTL expires at which point the server would query the SPF record again. Waiting until the TTL expires is certainly the safest option as you know any servers that have cached your SPF record will re-query the record. SPF affects all emails sent on behalf of a given domain. If a server not included in the SPF record tries to send mail on behalf of a domain there is a higher chance that it will be tagged as spam. In theory if -all is used then an unverified server should not be able to have mail delivered on behalf of a domain. However exactly how strict a mail server is with regards to SPF depends on the individual mail server and how the spam filtering is set up. I have another idea that I will post in a separate message. It will probably take a few minutes to get written up.

A lot of customers really don't like being asked for information that is not necessary for the successful delivery of their order.

The difference between -all and ~all is that -all is a stricter setting. It means that any server that is not included in the SPF data should be automatically refused for delivery. ~all is a bit more flexible in that it means that servers not included in the SPF are allowed to send email on behalf of that domain but they are not officially approved. There are reasons that -all might be preferred over ~all but for general use purposes ~all is probably a better choice. (-all might also explain why your incoming TB messages are vanishing.) I would also double (or triple) check that the IP in your SPF record is actually the IP of your webserver. No zeros that got entered as the letter O, no mistyped numerals, no commas instead of periods, etc.

When you say "the responsive mode is not working", what do you mean? When I visit your site it seems to work okay, at least the front page does. Maybe clear the Thirty Bees caches in the back office and clear your browser cache & cookies? Edit: BTW, you should create a new thread for your question rather than adding it to an already existing thread by a different user. Maybe @lesley can move this to a new thread?