Traumflug

That's disappointing. Filed as a bug here: https://github.com/thirtybees/thirtybees/issues/880

Some can get turned off in back office -> Preferences -> Customers.

Good question. To avoid such questions, removing two of the three algorithms is planned anyways. Unless PHP encryption turns out to be measurably slower than the others, it'll be the algorithm in the future, relieving merchants from the burden of making a choice. I think there is no real preference for one or another. All three work fine. Changing the algorithm is simple as well, it just logs out all customers and employees. They can log back in immediately, no need for changing passwords or such stuff. Shop visitors won't even notice.

I'd clone all five shops, then remove the four unwanted ones in the clone. No need to have these five front offices web accessible, there's only one back office. Trying to manipulate database contents directly would be a pretty complex thing. There are all kinds of connections between tables, finding them is really hard.

Looks like it's time to find out whether the database is actually working. If you have a shell, did you try to connect to the database using telnet? Doing this here I get this: $ telnet localhost 3306 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. [ 5.7.25-0ubuntu0.18.10.2T 4�U7oPlT_bACGMgmysql_native_password This means, a connection gets established. If there appears something like Connection refused, there is no server running.

Time to watch out for error messages. One place one can find error messages is the JavaScript console. On Firefox, that's menu -> Extras -> Web Developer -> Web Console. Another place is log/ in the filesystem, one can look it up by FTP. There are files with error messages, a new one generated each day. Third place is the error log of the web server. Location (and whether one exists at all) depends largely on the type of web server.

Files uploaded in back office should have correct permissions. If there are files uploaded by other means, e.g. FTP, one also has to watch out for the right file owner. To find out the right owner, one can look at a generated file, like the ones in cache/ or img/tmp/ (other than index.php). Permissions 755 should work, ideal is 644 (read, write, but no execute permissions).

To me it looks like the error message is empty. Not good. This is how it should look like if one tries to upload a too large file:

Filed an issue to not forget this: https://github.com/thirtybees/blockfacebook/issues/1 Regarding a solution, the task would be to find the language in the set of JavaScript variables (try console.log(window); in the browser console) and use this.

We might be able to help if you'd tell us what's going wrong. "not working properly" can mean anything.

Rebuilding thumbnails should help. Back office -> Preferences -> Images, last panel.

Obviously some trouble with module cronjobs. Table 'xxx_thirty.cronjobs' doesn't exist Very odd table name. And looking at this database upgrade script: https://github.com/thirtybees/cronjobs/blob/master/upgrade/upgrade-2.1.0.php#L32, somebody apparently forgot the table name prefix. Regarding shop recovery, is the shop actually broken? I'd try to go to back office using a new browser tab/window, it should work. To recover the module, it might be necessary to execute this one line in the upgrade script manually, using phpMyAdmin and the actual table name.

I see what you mean. The secret is, what Core Updater provides as 1.0.x is currently static. While the module its self is complete, there's still a background script missing which translates commits from the development repository (the one on Github) to the Core Updater repository automatically and for every commit. The latter holds release files, e.g. also all the files in vendor/. This script is forthcoming, of course, but not on the TODO list before the 1.1.0 release.

Changing order status would get tricky, because a VAT number isn't part of an order, but part of an address. A customer can add an address without also doing an order. Anyways, this snapshot of the improved module should explain how it works now: And here's yet another preview, which has this implemented: vatnumber-2019-03-13.zip

Wie das eben so ist, kann man nur Macken beheben, die sich auch nachvollziehen lassen. Wenn es Dir zu viel Arbeit ist, die Schritte, die zum Fehlverhalten führen, zu beschreiben, dann kann thirty bees da nichts machen. Dann wünsche ich mal viel Vergnügen damit, einen neuen Shop einzurichten. Scheint ja weniger Arbeit zu sein.

They indeed simply turn off this service without notice. Seeing all the trouble here I started implementing this request using the recommended SOAP protocol. Up to around 10:00PM the service worked just fine. Since then it just reports "Member state service unavailable". And it's not back online 2 hours later, at 00:15AM. Welcome to the Internet, European Community! Good news: the SOAP response can distinguish between a VAT number found to be invalid and a service not working. Now I wonder what to do with a missing service response. Slapping this into the customer's face likely means a lost sale, as he can't get past this without accepting to pay VAT. Maybe the module should accept the number, but also send an email to the merchant, notifying him about the VAT number being unverified.

Thanks for testing. Yes, Spanish VAT IDs need this blank trader name.

"Does not work", like this? (I just clicked the link above) This is starting to become a head scratcher. I also tried from the thirty bees server (which is located in Germany): $ curl 'http://ec.europa.eu/taxation_customs/vies/vatResponse.html?locale=EN&memberStateCode=DE&number=17101aderName=' | grep -i 'valid VAT number' % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 13423 0 13423 0 0 50469 0 --:--:-- --:--:-- --:--:-- 50652 <b><span class="validStyle">Yes, valid VAT number</span></b> I'll also ask @lesley, he's outside the EC.

Looks like this module doesn't take care of setting up its directories properly. Directory /public_html/eshop/modules/lpexpress/log needs write permissions. Your FTP client should be able to do this. Read, write and execute permissions for the user. Also, a bug report to the module author is a good idea. Such things are easy to fix, it just has to be done.

Not to forget modules provided by thirty bees partners, which can be found in the thirty bees store: https://store.thirtybees.com/

First idea would be to clean the cache. Back office -> Advanced Parameters -> Performance, button in the upper right corner.

That's the key part: /public_html/eshop/modules/lpexpress/logs): failed to open dir: Permission denied How did you put this module onto the server? By using the back office module page? Then it's weird, this problem shouldn't happen. By uploading via FTP? Then there's a good chance your FTP user isn't the same as the web server user. Remove it and use the back office page to upload the module ZIP (Menu -> Modules and Services, button Add a new module near the top right corner).

Hah, they're good at fooling developers 🙂 And thanks for your patience and testing. Here's a third version, tested with this Spanish VAT ID as well: vatnumber-2019-03-10.zip

Let's not forget this: https://github.com/thirtybees/thirtybees/issues/871 A fix for this issue is preferred, of course. String translations fall back to English if a translation is unavailable already, emails should do this as well.

If "latest version" means v1.0.8, then yes.