Traumflug

It works in a pretty trivial way: marking this checkbox enters the magic word "vatExemption" as VAT number. Magic of this word is, it gets filtered away when creating invoices. Other than that it works like a valid VAT ID. One can see this word when looking up the customer's address in back office. If the VAT number field there is empty, the module is likely not the problem. That said, Swiss customers often know they get VAT relief when ordering something in Germany. Switzerland isn't in the European Community, so taxes get calculated the same way as when shipping to e.g. the U.S.: no VAT. They're expected to pay Swiss VAT at their customs office, though.

I thought it might be something to do with the cache but the captcha isn’t even displayed. If a page without Captcha is cached, nothing on the planet will ask for loading the Captcha.

PageCache turned on, perhaps?

The controller needs to be in the right place: <module folder>/controllers/admin/. Else the PHP autoloader doesn't find it. And one has to delete cache/class_index.php in the shop installation after placing it. This file will get recreated on the next page request. If there's something missing in the description, don't hesitate to edit this wiki. Subscription is free and unrestricted, of course.

Jo. Dann ist Dein Shop wohl nicht optimal eingestellt :-) Ich würde es mal mit diesen CCC-Schaltern unter Advanced Parameters -> Performance probieren. Die alle einzuschalten macht die Seiten durchaus schneller. Da wird nur noch eine JS- und eine CSS-Datei geschickt, statt jeden der 30 - 50 Fitzel einzeln. Nur nicht einschalten, so lange man noch nicht Live ist und noch am CSS herum bastelt. Jede kleine Änderung erzeugt dann eine neue grosse Datei, das läppert sich mit der Zeit und füllt die Festplatte (in themes/<theme>/cache/).

PrestaShop documentation is still mostly right, if one ignores stuff for PS 1.5 and before. And there's this: http://jump-ing.com/traumflugs/writing_modules, very incomplete, still a number of useful tutorials. Two things: - File config.xml is no longer part of the module, it always gets created on demand now. - Back office modules should get implemented as controllers. Like described here: http://jump-ing.com/traumflugs/backofficemenu_entries Most modules still use their configuration page for their main user interface, which is no longer encouraged.

Auch bei den Details sehe ich keine Probleme: Bestenfalls diese Kleinigkeit, dass im Feld für die Newsletter-Anmeldung mokiert wird, dass da keine Email-Adresse drin steht, sondern Enter your Email. Das ist wohl ein Überbleibsel aus Zeiten, in denen die Browser noch keinen Platzhalter-Text verstanden haben.

Sieht doch gut aus:

Do you have full page cache enabled? This kind of cache is known to have flaws and needs further development.

Just to get an idea about how much work this is, I grepped through the sources for a couple of typical file system calls: none $ for F in file_exists file_get_contents file_put_contents file filemtime fopen is_dir is_file is_readable is_writeable mkdir; do echo -n "${F}(): "; grep -r "\b${F}(" | wc -l; done file_exists(): 3402 file_get_contents(): 930 file_put_contents(): 568 file(): 273 filemtime(): 285 fopen(): 827 is_dir(): 764 is_file(): 341 is_readable(): 147 is_writeable(): 53 mkdir(): 478 That's like 8000 calls to filesystem functions, which all need a change, then.

Updater module should work fine. These days with manual tweaks for updating are gone.

thirty bees supports external media servers already, see back office -> Advanced Preferences -> Performance, panel Media servers. The database can be on a remote server as well. Server side caching too, using a Redis server. The only set of files I'm aware of, which can not be put on an external server, is upload/ (files for customizing products) and download/ (downloadable products). PHP code it's self can't be put on an external server, with or without an additional filesystem layer. With this in mind I see no substantial opportunities to abstract something, other than filling a buzzword. Maybe I'm missing something.

I would like to have this turned on when I launch… When you launch. Not before.

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

In some cases, I had to do some fixes in classes directly in the modules folder. Well, if you provide these fixes to the community, they'll get added to official sources. Which allows you to upgrade and benefits everybody. Can be a pull request, a link to a commit, a patch by email, whatever is convenient for you.

There was an effort to add a compatibility layer for PS 1.7 themes: https://github.com/Traumflug/thirtybees/commits/theme17 It turned out to be a really huge effort, essentially duplicating all the rendering logic. Which means a whole lot of complications and as such, likely a lot of bugs and reduced performance. And unsolved questions, like how to make PS 1.6 modules rendering into PS 1.7 themes. Unless there's a $100,000 Crowdfunding, it's not likely to happen. This effort made barely the front page loading, without modules. My worry with buying a prestshop template is that in the future it stops working with TB and some of them are not cheap The whole point of thirty bees' existence is to not break compatibility. We'll always provide backwards compatibility and smooth upgrade paths.

Typically one buys a license for the module its self, no matter how it gets used. Using it with thirty bees is just as legal as making fine coffee with it.

Loosing the cart when logging out is expected. Logging out happens by emptying the cookie, so the (link to the) cart vanishes together with the cookie. See https://github.com/thirtybees/thirtybees/blob/1.0.x/classes/Customer.php#L1177 and https://github.com/thirtybees/thirtybees/blob/1.0.x/classes/Cookie.php#L202 Not sure why it's designed this way. There are methods to do a "soft" logout as well, just removing customer credentials (https://github.com/thirtybees/thirtybees/blob/1.0.x/classes/Customer.php#L1197 and https://github.com/thirtybees/thirtybees/blob/1.0.x/classes/Cookie.php#L371), so it's apparently not a result of code writer laziness.

To nevertheless help a bit on this one: one can easily check whether a module uses overrides: if there's no directory override inside the folder of a module, it doesn't. If you have a shell, list them like this: ls -d modules/*/override. And if you really want to avoid upgrades, you can edit the modules' main class, in the PHP file with the same name as the module directory. Watch out for a line like $this->version = '1.3.4'; and change this version to a larger one. Then delete files like config.xml and config_XX.xml to get them re-created automatically. This should avoid upgrade attempts until the edited, larger version is reached.

@briljander said in Official Mollie Module: But I guess he haven’t got that much back (moneywize) yet for his efforts No sweat on this one. It's true, there is no 5-digit monthly salary. Still it works out better than I expected. For example, I do these bought migration services and each time we can welcome a new thirty bees shop this way, some funds go to my pocket. One thing to not forget is that thirty bees operates in a pretty saturated market. Many shop solutions out there, so one can't expect rocket-like growth. With this in mind, thirty bees growth goes really well. Just last month at least 5 module/theme developers joined and now officially support thirty bees. Awesome.

@mockob said in Official Mollie Module: I believe there should be pinned topic in the forum, labelled something like :”The one and only developer who developed the fork has left it months ago bacause …” Did you see a topic in the PS forum announcing that some of their senior developers left? Probably not. That said, @mdekker is certainly not the one and only developer. Look at Github, development has continued. Even with me currently mostly working on "basement" things, infrastructure not visible to the public. And me being very lazy on pushing commits. Right now I have no less than 45 commits in my local repository for the migration module, waiting for a push. Maybe it's a bad habit of me to triple check whether things work out as planned before I push.

@colorful-ant said in PayPal Chaos - welches Modul?: schau bitte in beiden bildern ganz oben die ersten beiden zeilen SELECT idaeucemail FROM psaeucemail Wenn er das is_aeuc_email nicht in der Tabelle findet, wäre mal die erste Massnahme, den phpMyAdmin zu nehmen, um nachzuschauen, ob die Tabelle dieses Feld hat oder nicht. Oder vielleicht ein ähnliches Feld, was dann auf einen Tippfehler hinweisen würde.

I have no cache active Why not? PageCache has its flaws, but the other cache systems should work just fine. Even for development I keep Smarty cache turned on, with "recompile if something has changed".

Any ideas ? Update the modules. Keeping software outdated isn't an option.

Using Windows isn't exactly the ideal environment. This often ends up with glitches which are hard to tackle. Getting and old laptop and installing Linux there probably gives more satisfying results.