Traumflug

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.

Using the code from above, the traderName field is always empty, so it shouldn't matter. As this URL loads an ordinary HTML page, one can try in the browser: http://ec.europa.eu/taxation_customs/vies/vatResponse.html?locale=EN&memberStateCode=DE&number=171017618 http://ec.europa.eu/taxation_customs/vies/vatResponse.html?locale=EN&memberStateCode=DE&number=171017618&traderName= This VAT ID is my own, so it should be valid. However, the HTML page reads "Member State service unavailable. Please re-submit your request later." ... which the module recognizes as an invalid ID report.

Ha ha, my tools caught me. Copying this code here from the forum into the code editor also copied a Zero Width No-Break Space. Zero width means invisible, neither the code editor nor Gitk would show it. But good old vi on the command line did: Anyways, here's a fixed version: vatnumber-2019-03-08.zip Tested for basic functionality, this time.

What a huge posting. There's a module Duplicate URLs, which detects, well, duplicate URLs. URLs can get edited. Back office -> Catalog -> Product -> (click on product) -> tab SEO -> field Friendly URL. When migrating from PS, URLs with ID are kept. Those which used a friendly URL module before (every shop I migrated so far), have to deal with this manually. Obviously. ==> everything fine. Any fear left?

Shame on me. Yes, I changed only this one line, but didn't set up the module for testing. Error log (log/20190307_exception.log) should show the error.