datakick

That's not so simple. By introducing this class it become public api. Anyone could override it. Modules could expect it exists and use it... It's not much likely, but it could happen. By removing / renaming this class, we would create backwards incompatibility. And that's very much against he tb policy. I personally believe that, in this case, the functionality should be removed from core and moved to module. But if we decide to go this route, it needs to be done properly and safely. So the change won't take down anyone's server. You know, not the ps17 way.

core updater --> bleeding edge 1.1.x.

So you made it to thirtybees. Congrats. If the autoupgrade module is really not installed, it might be just some relics in your database. You can install one of my free modules - consistency checks - to get rid of it. https://store.getdatakick.com/en/modules/consistency

I'm sure it's not needed. Just give migration a go

What PS version are you on? You dont need to be on latest version to migrate.

This file looks ok. It should be config.xml with lowercase `c`, but it shouldn't matter much. The question is how the rest of the zip file looks like

Don't use it. Use redirect to stripe, and your flow should work correctly.

Hi, please follow these steps: install psonesixmigrator module to your ps16: https://github.com/thirtybees/psonesixmigrator/releases/download/2.1.0/psonesixmigrator-v2.1.0.zip perform migration install coreupdater module (should be visible in modules page) update your thirtybees to latest bleeding edge 1.1.x enjoy the stability and performance of your new thirtybees

Yes, this feature is on my todo list. However, for this to work without the need for overrides, the thirtybees core should first be modified. The 'sort by' is one of the oldest functionality, and in dire need for redesign / overhaul. Part of this overhaul should be option to extend sorting option via hooks. Once this is implemented, individual review modules can implement this hook, and provide custom sort by functionality

Well, the issue comes from pdf generation tool. It's possible that you have recently changed order status and it now newly generates invoice. Another possibility is that you have modified pdf templates, and added reference to remote image.

There are only few explanations your server settings has changed (maybe you have started using new php version, etc) code never went into this particular branch (pdf generation)

That's not software issue, this is server configuration issue. Your server does not have curl library installed

Go to 'Customer groups', and check enabled modules for each group

https://www.google.com/search?q=call+to+undefined+function+curl_init()

I agree that this should be changed. I don't want to say 'fixed', because I don't really have problem with sending *server generated* password over email in plain text. I actually believe this is more secure than having user entering new password in online form. The reason I support this change is that this flow is not standard these days. It can surprise users, and it can even anger some of them (unjustly). That's not something we want. However it's not easy to implement this in core. The functionality itself is pretty easy to implement -- it would be few hours of work, max. But it requires new template, which is a theme responsibility. We could add this new template to both *community* and *niara* themes. But we can't do the same for third party themes. Which means that password recovery functionality would not work anymore, if you used commercial themes. To overcome this problem we first need to come up with some mechanism to have new templates. There are many ways to do this, for example template inheritance. Unfortunately, it's much more complicated to implement such mechanism.

That's how recovery works in tb. You don't enter new password, it is generated and sent to you via email. If email does not contain new password then check your email template: password.html /password.txt

This is a bug that reproduces only if you use language that has iso code which is also sql reserved word. Like in your case *in* Thanks for reporting it https://github.com/thirtybees/thirtybees/issues/1250

You can use my DataKick module. It is designed to help with exactly these kind of things. You could: 1) create a custom field on your product (or combinations) named 'Threshold', and then assign different thresholds (in days) for every product/combination. Alternatively, you could create such field on Suppliers, Manufactures, Categories, etc... what makes sense 2) Create list of products with quantities below the threshold 3) Optionally, you can create scheduled task that will daily send you email with exported list of products to order (as csv) My module has 14 days trial period, feel free to install and try it. Ask questions here if you have any (I'm sure you will have some, as it's a little bit more complicated module that usual)

Actually, this should be the only way. The download link @WildToddMan used is to clone / download repository content. That's not necessarily the same as a ready-to-use module. Many modules must be *build* in order to have working product

I personally believe that product miniatures should NOT have rich content metadata. Especially when you display them on product page - for example if you have list of related products, "customer also bought", or "other products from this category". In this situation, google has hard time to understand what the page is about. From google's perspective, the product page contains multiple products. Sure, one of them is primary, but how should google know this? The primary goal of google is to understand and interpret the page. Adding too much noise to the page is not helping this, I think. I strongly believe that, in this case, less is more. I have it implemented like that on my website, and I'm very happy with it. I have zero warnings/errors in search console, and more importantly - my rich data are displayed correctly in search page result.

But to answer your original question: you can edit method ErrorHandler::errorHandler. If this method returns FALSE, then the standard error handling will take place (error or notice will be logged into server's log file). So, you should add code that (conditionally) returns true for error levels you don't want to log. You can do this for specific notices messages as well - for example, you can ignore any notice or warning raised from specific php class. Also, please don't change core file. Use override system instead.

What you are trying to do is modify the code to NOT generate these notices/warnings. While that's valid approach, I think it would be better to tweak your web server logging to log only levels you want. So when php application emits NOTICE, it will be ignored.

you can use core updater to update to bleeding edge. Or do it manually

try to update to latest version

this could be theme issue. What theme do you use?