dynambee

Governments often don't work on common sense so I wouldn't rely on a common sense approach to the problem. I suggest asking your accountant about it because they will have a good idea how it should work.

Unfortunately zip codes are often not a great way to define sales taxes but without a custom module (which AFAIK does not exist for PS or TB) it's all there is. You can get zip code based tax tables for free from here. They also explain why in some cases using zip codes for tax tables isn't a good idea, which is also why they give the zip code tax rate data away for free.

After installation it remains /admin. I think it actually gets changed after the first access to the /admin directory. I never noticed this before as I always renamed it myself at the same time as I deleted the /install folder. I have never used the word admin in any of my /admin folders and have never had any problem with this. I just spent a bunch of time digging around in Google and can find no mention of a PS 1.6 requirement that the /admin folder name start with admin. Did this change with TB? Can you point to anything that shows this as a requirement for TB and explain why it would matter at all? There's no need for comments like this. My skin is plenty thick and your snide remarks do not bother me but they might bother other people. Let's keep it professional.

Which Cloudways VPS provider are you using, which VPS tier, and what is running on the VPS? I used to be a Cloudways customer (before their horrible support drove me away) and didn’t have problems like this. I suspect that your VPS might be at its limit (not enough memory or not enough CPU grunt) or that the underlying hardware might be too far oversold.

Why not create the customer in the front office, and then use @datakick‘s excellent and free Login as Customer module to create the orders? Also, if you are getting long delays when creating customers and orders it might be related to your SMTP server and the confirmation emails being sent. Many SMTP servers intentionally have long delays for connections (called tarpitting) to make them unattractive spam delivery targets. Try disabling the emails or using a different server and seeing if the delay disappears. If it is SMTP delays then the only solution is to use a server that doesn’t have such a delay. We switched to Postmark for that reason, and for the improved delivery success rate.

Yes, you can ignore the error if you are confident that your server supports TLS v1.2. The error happens because PayPal used to provide a TLS test server (tlstest.paypal.com) but they no longer do. The DNS record for that URL no longer exists and any test that relies on that URL will automatically fail, regardless of the actual server configuration.

Is anyone using CHEX in combination with the Panda theme? How is it working? @datakick, do you know if CHEX should work with Panda? Any problems that should be expected?

After digging around a bit I think the test code is in the /classes/ConfigurationTest.php file. Starting from line 324 is function testTlsv12(): public static function testTlsv12() { $guzzle = new GuzzleHttp\Client([ 'verify' => _PS_TOOL_DIR_.'cacert.pem', 'timeout' => 20, ]); $success = false; try { $response = $guzzle->get('https://tlstest.paypal.com/'); $success = (string) $response->getBody() === 'PayPal_Connection_OK'; } catch (Exception $e) { } return $success; } Change it as follows: public static function testTlsv12() { $success = true; return $success; } This will force the test to pass regardless of if your server is compatible with TLS 1.2 or not. Later, after installing the PayPal module, you will need to follow the directions in my first reply to check if you have TLS 1.2 compatibility and then disable the PayPal module TLS test as well.

That's odd. I installed TB 1.1 earlier today and was able to get it installed even with that error. Maybe click the "refresh these settings" button once and then click Next? Edit: The PayPal module changes happen after the system is installed and after you have installed the PayPal module.

Okay, I figured it out after some more googling. I forgot that the default setup for my server includes mod_security being enabled, which is *generally* a good thing but isn't good for parts of TB. After disabling it everything works fine. I may try to figure out a configuration that doesn't cause TB to crash or I might just leave it off.

I nuked the above site and reinstalled it again. Fresh clean install but still getting a 403 Forbidden error when I try to use Core Updater. I have another TB site on the same server where Core Updater is working perfectly. How can I troubleshoot this? I have tried changing file permissions, reinstalling the site, reinstalling core updater, nothing works. Immediately after I click on the "Compare" button it happens. I have tried Chrome & Firefox, cleared caches, tried restarting the web server... I'm at my wit's end, I can't update the site. 😞 Help!

TB1.1.0, with no updates done. I have one test site where the /admin folder is still named /admin. However if I log out of the back office the /admin folder gets renamed to something else. Most recently /admin281cw0mah. If I set it back to /admin and log in/out again the same thing happens, but with a different random name. I generally rename my /admin folder to something else after installing a site so I haven't seen this happen before. Is it normal behavior? Randomly renaming the folder and not telling the end user about it seems like a poor idea. If they don't notice and aren't particularly technical they won't be able to get back into their admin panel!

Better than it could've gone, guess we get to wait and see how things unfold going forward.

You don't have to do anything at this point, just click on Next. Once you get TB installed you can follow my directions above. This isn't a TB-specific problem. Everyone used the same PayPal server to test TLS 1.2 compatibility (it was designed for it) and then PayPal just decided to take the server down. Thanks PayPal.

Unfortunately PayPal killed the domain that was used to test for TLS 1.2 compatibility. Why they did this is a mystery but it means the TLS 1.2 test will always fail. You can test for TLS 1.2 compatibility from the shell with this command: openssl s_client -connect google.com:443 -tls1_2 If you get a successful connection to Google from the command line with that command then TLS 1.2 is working. Unfortunately this still won't help with the PayPal test, it will always show as failed. You can edit the /modules/paypal/paypal.php file to force it to always return OK though. Starting on line 401 of the paypal.php file: comment out these lines by adding // at the start of each line: $response = $guzzle->get('https://tlstest.paypal.com/'); if ((string) $response->getBody() === 'PayPal_Connection_OK') { $this->updateAllValue(static::TLS_OK, static::ENUM_TLS_OK); } else { $this->updateAllValue(static::TLS_OK, static::ENUM_TLS_ERROR); } Then you want to add this line: $this->updateAllValue(static::TLS_OK, static::ENUM_TLS_OK); You can make a blank line if you like or just put it on line # 402. My tlsCheck function looks like this: protected function tlsCheck() { $guzzle = new \GuzzleHttp\Client( [ 'timeout' => 10.0, 'verify' => _PS_TOOL_DIR_.'cacert.pem', 'http_errors' => false, ] ); $this->updateAllValue(static::TLS_OK, static::ENUM_TLS_OK); //$response = $guzzle->get('https://tlstest.paypal.com/'); //if ((string) $response->getBody() === 'PayPal_Connection_OK') { // $this->updateAllValue(static::TLS_OK, static::ENUM_TLS_OK); //} else { // $this->updateAllValue(static::TLS_OK, static::ENUM_TLS_ERROR); //} } Once you have this done when you click on the "Check for TLS v1.2 support" button in the PayPal module it will ALWAYS tell you that TLS 1.2 is supported, even if it is not. That is why you have to manually check if TLS 1.2 is supported using the shell command I listed at the start.

No problem. I live in Japan and have been dealing with multi-byte characters for nearly 30 years. 🙂

64x4=256 bytes. 255 bytes is the maximum, probably because the string is null terminated using up that extra byte. Edit: Or to put it another way, 63 characters instead of 64 for the same reason it's 255 bytes and not 256. 😉

32 characters is a lot of combinations but not very many characters for descriptive filenames. Yes, 255 bytes per filename and max 4096 bytes for the entire path. However UTF8 is a variable length encoding system. A-Z a-z 0-9 and other basic English characters fall into single byte encoding. So if someone is using English filenames then up to 255 characters is fine. However if you get into other alphabets each character can take between 1 and 4 bytes, depending on the alphabet and the character. Fun stuff. So the TB platform itself can probably increase the filename safely to 63 characters. If specific users wish to increase it beyond that then they need to be aware that they could run into problems depending on the alphabets they use.

No, the database structure is set up in such a way that each category can only have one parent category. While nothing is impossible it is impractical to change such a fundamental part of the products/categories system. You can assign each product to more than one category but if you are going to have multiple categories called "hats" then you will want to include the category ID as part of the URL. Otherwise you will end up with non-unique category URLs and this will get very messy.

The best part is the hovertext though so go to XKCD and hover over the comic. (On iOS if you long-press on the image the hovertext will pop up. Android is probably the same.)

Looks like the carriers themselves are set up then so for some reason the module isn't working correctly. The next step is what @lesley said, enable error reporting so it is possible to see what is causing the module to fail.

They offer whitelabel email hosting, you can use your own domain and logo/branding for webmail. You have to buy an SSL cert through OpenSRS though so that's about a hundred bucks a year. Since I'm not reselling email I don't care what the webmail domain is and just use the standard OpenSRS domain to access webmail. Considering the amount of work necessary to properly run a mail server (and having many clients rely on that server for their business) I would feel a lot more comfortable reselling something like OpenSRS than building a server from scratch and selling that to people. Unless your labor costs are insanely cheap or you're selling many 100s of email accounts it is almost certainly going to be cheaper to use OpenSRS, too.

Okay, I have put a couple of domains onto OpenSRS Hosted Email so I have a few initial thoughts about it now. The initial setup (adding the domains and setting up email DNS authentication records) is a bit more involved than I would ideally like but anyone who has set up domain-level email before will be fine with it. The interface is a bit old-school and clunky, but it works. They are very big on avoiding people using their email service for mass mailing. This is both good and bad. It's good (excellent in fact!) in that it means that your emails are less likely to be tagged as spam. As with all email providers, your mails come from one of a few shared outbound SMTP servers so keeping those servers clean and free of spam reports is very important. On the downside though, newly created email addresses have quite low daily outbound message limits that increase slowly over time. The first address I created was allowed to send 20 emails on the first day, 29 emails on the second... It seems it increases automatically over time as the address is deemed more trustworthy. I don't know how this curve will work or when the address will reach a higher level. You can also request that limits be increased faster if necessary but not having tried this I can't say for sure how easy a process it is. Running a couple of spam-checkers on messages sent from their servers came back with perfect "not spam" scores once the DKIM/SPF/DMARC entries were set up in the DNS server. Their webmail interface is very clean and nice to use. It's not quite as fast as Gmail but it's not unreasonably slow. I will probably mostly access email through email clients and mobiles, but it is fine through a browser in a pinch. I sent some sample emails to various Gmail and Google Apps accounts and all messages came through without problems. Not being able to deliver email to Google was a major reason to abandon the idea of self-hosting email so I'm glad to see that this works without trouble on OpenSRS. So overall I am satisfied with the service. I would need to set up 80 different email accounts before I reach the costs I was paying to self-host email and I don't expect to reach that level of email anytime soon. I will keep a couple of domains on the free Google Apps tier that they are on now just so I don't have all my email eggs in one basket (and it's free so why not) but otherwise I will be migrating all email to OpenSRS over the coming weeks and months, and all new domains will have OpenSRS email set up for them. The only thing it is really missing, IMO, is a way to push email notifications to mobile clients. If anyone has questions I can do my best to answer, especially as I add more domains and get more used to the system.

What happens further through the checkout process, on step #4 where carriers are usually chosen? Do all the different carriers show up there properly? Can you post a screenshot of that?

I just made a fresh install of TB 1.1.0. I've installed a couple of modules and made some minor changes but haven't done anything major to the installation. File permissions are 775 for folders and 664 for files. File ownership is correct. I have reset permissions & ownership multiple times to make sure they are right. When I go to the Core Updater module and click on Compare (regardless of the options I choose, but let's say Bleeding Edge, 1.1.x, don't ignore community themes) immediately get a 403 forbidden error. It says, You don't have permission to access /admin/index.php on this server. The address bar contains https://www.mydomain.com/admin/index.php?controller=AdminCoreUpdater&token=tokenremoved When I do the same thing on one of my dev sites running on the same server with the same settings and the same file permissions everything works fine and I can update the TB installation. Anyone have any ideas what might be wrong?