datakick

ScriptResource.axd This doesn't look php related

Did you enabled debug mode, as @zen suggested? That would have give you some error code, and we could give you ideas.

Check that module is allowed for all customer groups

What page in particular is affected? Please share url, so we can compare it with the http://4kidspoint.pl/robots.txt It could be related to these sections: Disallow: /*?orderby= Disallow: /*?orderway= Disallow: /*?tag= Disallow: /*?id_currency= Disallow: /*?search_query= Disallow: /*?back= Disallow: /*?n= Disallow: /*&orderby= Disallow: /*&orderway= Disallow: /*&tag= Disallow: /*&id_currency= Disallow: /*&search_query= Disallow: /*&back= Disallow: /*&n=

Software and digital services

Weird. Could you five me access to your back office, so I could investigate?

When you enable ASM make sure your carriers are associated with warehouses. And of course, associate product with warehouses as well.

This is related to php8 and it's Attribute class. Even if you don't run on php8 there is already a polyfill that introduces this class, and that breaks the whole tb store. I'm currently working on this issue, it will be fixed soon.

INDEX (cart_id, order_reference) That's composed index, based on two columns. This index would be used only if the join contained cart_id column as well. But in this case, the join contains order_reference only, so db will happily ignore it. It's possible that there is bug in php code -- maybe the join should contain cart_id. Or if the php code is ok, then there should be standalone index with this order_reference column only.

The code is perfectly fine, there's nothing wrong here. It just adds additional table to the query that fetches orders. The problem is that your database select bad plan to execute this query. The solution is to help the database -- create index that it can use to optimally retrieve data. Something like this: CREATE INDEX mp_order_reference ON tb_mollie_payments(order_reference); With such index the query will run much faster, probably

That shouldn't be a problem - both normal and guest accounts are the same thing, they should be logged in correctly.

Can you post some screenshots? Or PM me url to your website, I'd like to have a look at it

Well, merchantsedition is a fork of thirtybees. It has additional 23 commits that mostly changed formatting of files. So the statement is (mostly) correct -- if you update your thirtybees using core updater to bleeding edge, you will end up with latest version of thirtybees. Which is the same codebase as merchantsedition is using right now (minus formatting)

Hello everybody and happy new year. I spent a lovely Christmas / end of the year with my family, without access to internet, computers, and so on. I feel fully charged and ready for this new challenge. So let's do this. I must confess that I was a little dishearthed with the cold response to the announcement. While I understand you guys don't really care if this project continues under the same name, it's a big deal to us. Fork would be a very different starting point. It's very nice to have hundreds of active websites using our platform already. And it's amazing to inherit existing thirtybees infrastructure (forum, websites, demo, api servers, mail servers, translations, deployment, testing). If we were to start from scratch, it would take us a year to get to this point. The effort to achieve this would be huge, and nobody would really benefit from that. Especially not you, merchants. After a lot of mundane work we would end up at the very same spot we are now. If we weren't able to close a deal, I'm not sure if we would even try to do this. So yeah, we were really excited about it. But I am fully aware that you don't really care about all of this. You expect roadmap, business plan, etc... and it's a fair point. So let me talk a bit about this. Monetizing strategy: Our team have talked a lot about different ways to earn money that are needed to keep this project afloat. Realistically there is only a handful of them that we can pulled off, considering our limited resources. For example, we have dismissed the idea of providing SAAS or PAAS service. In the first few months, the majority of revenues will come from the support services that we will provide to merchants. This means that portion of my development time will be allocated to paid support. We believe that this is the best way to bring in some money right away. Also, the existence and availability of official support will surely make platform more attractive to undecided merchants. Support services revenue model does not scale well, though. There is only finite amount of time we can provide. Even though we want to bring other developers aboard, the time will still be a limiting factor. We are fully aware of this and we have few other plans for a long run. Development: First of all, I want you to know that I will devote 100% of my time to this project, starting February. Currently I'm finishing my current development contract, and closing my existing activities (for example support service I provide via datakick agency). That means that this month I will work on thirtybees only part time. But come February you will start to see some real progress. As I wrote above, part of my time will be dedicated to support, something between 30% and 40%. The rest of my time will be dedicated to github maintenance - I will scrub and address each and every issue, pull requests, doing code review, etc. bugfixing - issues will be categorised by severity, and some of them will be fixed. Not all - that's just not possible. I expect to spend 15% of time on this. That should be good enough to fix around 40 serious issues per release. new feature work - for every release we will select (with your help) some new features, and we will commit to implement them. I expect to spend around 25% of my time on this area. If you have some ideas what you would like to see in the core, or idea for new module, let us know (unless it's multiple feature value, I've heard that one 100 times 🙂 platform enhancements - the rest of my capacity will be dedicated to platform enhancements. These are development tasks that you, as merchants, will not immediately benefit from. But they just need to be implemented. Some of these tasks will not be very popular, I'm sure. For example, I want to implement some tracking in order to have good knowledge about system usage. Such information will allows us to focus our efforts on areas that are heavily used. (But don't worry, we will be very correct. No data without your consent will be sent to us). Other tasks from this area will be more appreciated, such as php 8 support. Or tool to create custom field for product or customers, or to edit properties of existing fields. Release cycle: Our main focus always was, and will continue to be, on stability. Based on our experience we strongly believe that merchants don't really want, or need, too many releases. So we decided to have just two major releases per year. Other than that, we will have monthly bugfix releases, that will contain high severity bugs only. There will also be bleeding edge release that will always point to the latest development (just for brave). Bleeding edge is de facto Release Candidate. All of these releases will be available for download, and of course via core updater. The first official release will be prepared in a few days. It will be branched from current bleeding edge. Partnerships: For thirtybees to succeed we need to have thriving ecosystem. That means both merchants and third party developers. We have quite a lot merchants using our system already, which is a good news. Unfortunately the situation with module and theme developers is more worrying. Sad fact is that there aren't many developers that support our platform at the moment. And we need to change that. We have a plan to actively outreach to them, offer our help with adapting their modules and themes, make it easier for them to become part of our platform. If you know about some module you would like to see adopted, PM me details!

It was answered many times. It is also fixed in bleeding edge. Please update your store to 1.1.x, or simply ignore the warning

if (!extension_loaded('apcu')) { throw new PrestaShopException('APCu cache has been enabled, but the APCu extension is not available'); } This exception is thrown because apcu php extension is not loaded. You need to configure your server. How to do this exactly depends on your hosting provider, on platform you are using, etc. For inspiration: https://serverpilot.io/docs/how-to-install-the-php-apcu-extension/

I could look into that, if you could provide exact reprosteps for vanilla installation of thirtybees 1.1.x. I mean what taxes I need to enable, how to create order, etc...

Please don't do that, this is one of the most important part of the code. It's like replacing car engine because your 'Check engine' light is on.

Thirtybees core supports 'Shipping options', but it's a little buggy. There were few bugs fixed in bleeding edge, but it's still not perfect. When your cart contains products that can't be shipped together (for various reasons), thirtybees will try to calculate a multi-carrier shipping option. Unfortunately, not all themes and/or OPC modules can handle this correctly.

what do you mean by 'country selector' ?

Works fine for me

@Theo please show some screenshots, I don't really understand what the problem is

That's actually on a backlog. Unfortunately there is not enough time right now

I suspect you are using version 1.0.7, as it's the only one compatible with ps16. In file heidelpay.php, line 57, the module specifies compatibility as: $this->ps_versions_compliancy = array('min' => '1.6.1', 'max' => '1.6.99'); Change this to $this->ps_versions_compliancy = array('min' => '1.6.1', 'max' => _PS_VERSION_); And you should be fine

yes. when the new email is sent is governed by the trigger you choose