I cleared the cache multiple times and also waited 24h before posting here to be sure it’s not a cache issue.
@moy2010 That’s the thing. I don’t understand the structure of the language modules.
I think I only edited the translation files - when I go Localization>Translations>Installed Modules>Core>English I see all the “original” entries of the developer and my new ones are translations. But I don’t know where to look for the original entries…if I go through the module, it looks like they’re scattered here and there in different files.
But, to answer your question: In Localization>Translations>Installed Modules>Core>English the translated fields are all filled with my edits in en.php, not with the default ones.
In Localization>Translations>Installed Modules>Core>German the translated fields are only partially filled with my edits in en.php … and not at all from de.php and not from the default ones, either.
If anyone is interested by this, I did solve my problem by adding a product attribute id parameter to the public static function getIdTaxRulesGroupByIdProduct() in the Product class and worked my magic in there. Not really a general fix but it is working for me and I can give you more details if you’re ever looking to do the same (which I doubt since I may be the only one having this particular issue).
Of course had to adapt the following classes/controller that were calling it as well:
I think it depends a bit on what the goal of this one-domain-per-country strategy is. It can be used to adjust offerings to local needs. To get this, there’s multishop. As far as a quick research goes, language settings are for all shops together, but one can always choose browser’s default language.
Another one might be to deal with customer habits. They’re simply used to type “es.myshop.com” over “myshop.es”. In that case, multishop comes to the rescue, too, because it allows to set up many URLs for a single shop. They all get redirected to the main URL, then.
I originally wrote this for ps 1.4. This back in the day when localizing on a url was all the rage. orginal ps has a very robust by country configuration support which is what originally got me interested in this cms.
this is even compatible with gsitemap in that your old /en/ would be presented en-us for example. googole LOVES this. The one bit missing with this work new feature is where we alias a language pack so that we could define ‘many’ languge/country codes from one language…es-es aliased to es-countrycode…anyway…that is current ‘best practice’ to localize by country/region content.
Another important factor, choosing a multishop solution when there you do not share ‘everythinig’ and even then creates a lot of challenges most shop managers struggle with. Remember addon’s does not have a ‘ps ms compliant’ attribute. So if shop is not going to share pretty much everything then having separate installations is much better solution. sure with default theme modules ms functions well enough but through in a 3rd party theme and rich module eco you had better have good support.
It does seem to be an issue with the postfix server being slow to accept incoming connections. I seem to remember reading that this is a security measure of sorts but I can’t find information on it right now.
Rather than monkey around trying to fix this issue I think I am going to use Postmark to send out transactional emails such as welcome messages, order receipts, and bank wire payment details. Postmark has a very fair pricing system where you buy credits for emails ($1.50 per 1000 for small users) and the credits do not expire. No monthly charges, just pay for what you use. First 25,000 emails are free.
However, this does leave me wondering why the new user signup isn’t delayed like the bank wire purchases are. The only answer I can come up with is that perhaps the welcome mail is being sent asynchronously while the order details mails are synchronous and thus causing the delay?
@mdekker, any thoughts on this? Possible to send all mails asynchronously to avoid any delays?
It’s not too surprising that even short passwords expose the problem, because passwords are stored encrypted and many encryption mechanisms generate an encrypted string of constant length.
All the encryption stuff is in need of an overhaul anyways, because PHP 7.1 now officially deprecated the mcrypt extension, the current default encryption mechanism. And there are three different encryption mechanisms while two are sufficient (a non-reversible one for passwords and a reversible one for cookies and exception reports). This is tracked here: https://github.com/thirtybees/thirtybees/issues/386
Hmmz, at first I was like, why would I want to empty the tb_mail table? It is about cleaning up, not removing. But then I saw you were talking about resetting orders, customer data etc. It makes perfect sense to add the tb_mail table as well, so I’ll add that to the list. Thanks for your input!
Looks like your connection to thirty bees forum was lost, please wait while we try to reconnect.