Traumflug

How about this one? https://store.thirtybees.com/shop-modules/front-office/block-links You should find in in back office -> Modules already, search for 'Block Links'.

Is it this one? https://github.com/thirtybees/thirtybees/issues/551 Workaround is to turn off full page cache for index.

People here cannot take the the fact that there are errors in the TB??? People can take it. That's why they don't moan about the fact. Negative words don't help fixing bugs. Helpful is to describe what's going on, as exactly as possible. What worked in 1.0.4, what no longer works in 1.0.5. If you can find the time, do a Developer Installation and see whether it happens there as well. Then you can go through all the commits step by step to find the one which introduced the regression. A strategy named bisecting helps for quicker results. To my knowledge, there are no changes regarding the full page cache between these two versions, so it's apparently a side effect of some other change.

Is there a way to update it without replacing the theme? Delete it from the unpacked ZIP file before uploading. Just as it's done with the the install/ directory. To update your custom theme, apply these commits manually: none Merge pull request #44 from TrueXakeP/patch-1 (Feb 23, 2018) Merge pull request #48 from gonssal/fix-webp-product-view Merge pull request #46 from yaniv14/1.0.x Merge pull request #49 from TrueXakeP/fix-reorder-shown Reversing product page webp support Fixed category image responsiveness Added clicking on text to change carrier Fix price range display for RTL languages. Remove empty file order-advanced.tpl-eleazar. Merge pull request #54 from yaniv14/patch-1 Fixed logic on shipping (May 16, 2018) All of which can be found here: https://github.com/thirtybees/community-theme-default/commits/1.0.x

https://github.com/thirtybees/thirtybees/issues/554

Not yet. Also not a big threat, because this exploit works only if a customer with a cart and an employee use the same password. To be safe, make sure this isn't the case. This exploit somehow (it's complicated!) manages to extract a password hash from a customer cookie, then uses this hash to assemble an employee cookie, which allows back office access. If there are no identical passwords, it doesn't work. Still I plan to apply the fix, of course. Part of the fix is to remove Blowfish encryption (in favor of a safer encryption).

Here we go: VAT Exemption Module v2.1.0 release See release notes there on what to do beyond upgrading the module to get this new feature working (short of waiting for thirty bees 1.0.6).

One thing for sure: related code is complicated :-)

27.18 x 3 = 81.54 81.54 + 17.98 = 99.52 Looks like rounding is right, just the total of the first line displays one cent too high. It displays $81.55, while it calculates with $81.54. I've recorded a Github issue to not forget this: https://github.com/thirtybees/thirtybees/issues/553

Partially funded by a client, VAT Exemption Module has learned to deal with VAT exemptions not related to a VAT number. In some countries other reasons for such exemptions exist, now customers can declare their qualification for that. Merchants have to verify this qualification manually, then. How does it work? First you'll notice an additional switch on the module configuration page, Allow manual verification: With this switch set, a customer's address entry form gets an additional checkbox: Having this box checked and being logged in, customers see prices without VAT. On the front page, on product pages, on checkout, and invoices will state '0% tax'. This is the point of this feature. To see whether a customer thinks he's qualified for VAT exemption, you can look up his address in back office: If you see a VAT number reading vatExemption, s/he claims qualification. To remove the qualification (if the manual verification failed), remove this word and save the address. To add the qualification manually (e.g. a customer who forgot to check the box and applied later), add exactly this word in the VAT number field. It's a magic word, the only VAT number not appearing in addresses, still setting taxes to zero. I think the module as well as core and default theme adjustments are complete, but being the guy I am, I'll get some sleep and take another, fresh look tomorrow before pushing it. Stay tuned. It'll be module version 2.1.0, then. P.S.: this module was renamed from European VAT Number to VAT Exemption Module about a week ago. Just a change of the displayed name, on disk it's still vatnumber.

Admin note: it looks like you tried to post three times, landing in the moderation queue each time. I'll remove the other two postings. If one of them has something which is missing here, please add it here as well.

Well, the simple workaround is to keep full page cache for index off. Other shop solutions have no full page cache at all, so thirty bees can't be worse. As I can reproduce this (from a desktop), I've recorded a Github issue: https://github.com/thirtybees/thirtybees/issues/551

This is how the back office page for Customers looks with a default installation, for reference:

I'd guess you should turn on Enable Opt-In. Without this, customers are always In, without the Opt part.

Can't tell whether it's indeed fixed. Ideally you'd create a step by step test case using a default installation and test this. This can serve as foundation for a Github issue, then, speeding up a fix.

Alright, I reverted this change. However, instead of using just show() and hide(), it now uses slideDown() and slideUp(), to be more intuitive about what's going on. Before it was hardly noticeable that the list of fields got longer. Thanks for the help!

@colorful-ant The VAT number is public, there isn't much to hide. The normal tax number is not, but also not requested in this place. @nickon I think intended behavior is to always send an invoice. Private customers get one with taxes and without VAT number, company customers get one with their number, without taxes. And then there's module vatnumber, which does the right decision depending on shop country and customer country. @ everybody Thanks for the opinions, I'll push this, then. Let's see how it's recognized by users. In case it's not appreciated later, it can be reverted easily. That's why we have source code version control.

Are you sure your installation files are owned by the web server user (www-data or similar) ? Operating the shop will create additional files, e.g. uploaded pictures. You can't chmod all of them.

Also depends on the expected number of customers. For all those niche shops, which are happy to have five sales a week, simple hosting is entirely fine.

In many countries, the VAT number plays a substantial role regarding tax handling. And there are hints that people don't find the field to enter this number intuitively. It's on the page where customers add/edit their address. This is current behavior, the field is entirely hidden/removed with no company name entered, no hint on its exsistence: New, proposed behavior is to not hide, but dim the field. This way people get aware it exists, but it's also a bit a distraction for non-company customers, of course: With a company name entered, both look the same, field fully visible and usable. What do you think? Is the proposed change an improvement or a step backwards? P.S.: The change is pure JavaScript, so themes can override it easily. And please don't ask for a back office switch to change between both, there are currently more important things waiting.

I thought it was only in firefox but you also see the error in chrome after deleting the history. This part isn't much of a surprise. PHP code runs in the server, not in the browser. What bugs me a bit: the error message asks for a Symphony file, which shouldn't be part of the thirty bees distribution. Do you happen to run not an unpacked ZIP file, but a Git clone? In the latter case, did you run composer install ?

Probably not without editing the database directly. Table PREFIX_specific_price, I'd guess.

Certainly a thing to test. Perhaps the bug is still present.

This is probably key to the solution: Translations for thirty bees version 1.0.4 not found either. It's not a permission problem. It's a problem of your server not being able to download translations.

Uninstall module productcomments.