datakick

Could you run this statement in phpmyadmin and show results: SHOW CREATE TABLE ps_page_cache;

Using ftp or ssh - delete directory cache/smarty, and then re-create it again

Use core updater to upgrade to latest bleeding edge. Use core updater to check that there are no database differences. Then try again. If this doesn't help, then check what overrides you have installed - there's overridecheck module for that.

Isn't it beautiful how one can easily update shop in just a minute?

It's as safe as any official release. Unfortunately, there is no QA team that would thoroughly test each release. Every release is just an arbitrary point in time / code base.

Update to 1.1.x / bleeding edge

What tb version are you running?

This commit might fix the issue https://github.com/thirtybees/thirtybees/commit/538036cc7faa2d9129ffbd2810d5cbaf25d9fbff

This is a forum, one of many forums I'm participating in. I'm subscribed to hundreds of threads. Unfortunately, it's very easy to miss/forget some message.

Yes. It's number two on the todo list (for this project) Addresses are filtered by currently selected country. If you select destination country for which no address exists yet, you will be asked to enter new one. You can switch to the list of existing addresses and choose one, but that will change destination country as well. Which mean recalculation of the cart, shipping rates, etc...

I don't follow. Can you please explain a little bit more?

Not sure if this is a bug, really. It's definitely nuisance / ui glitch, but I don't think it prevents anyone from completing the checkout flow. It's on my list of todo tasks. Very low priority, tough.

If it works, please let us know. And ideally submit a pull request, if you find some time.

I filed an issue for this: https://github.com/thirtybees/blockwishlist/issues/7 Try to change line 370 - https://github.com/thirtybees/blockwishlist/blob/ba50a17bd794fec127e4690c224d13fb7359fd5b/blockwishlist.php#L370 from $this->smarty->assign(['wishlist_products' => false, 'wishlists' => false]); to $this->smarty->assign(['wishlist_products' => false, 'wishlists' => []]);

There's no reason for them to not work. However there can be some initial problems after theme installation, as many ps16 themes comes with flawed config.xml file. Thirtybees more strictly following instruction from this file - ps16 was more lenient here. Which means, after theme installation, some modules might not be enabled, and you will need to do it manually. because thirtybees uses newer smarty version than ps16, there is and infamous issue in checkout page. This bug manifests with Cannot use object of type Carrier as array error message. The issue is well understood, but unfortunately it can't be fixed in the core. It must be fixed in individual themes. Fortunately, fix is fairly simple. Note that not all themes are affected by this issue

Hi @haylau, thanks for the question. I'm really glad you like my module. Your use case can be done with a bit of 'datetime arithmetic'. Let me guide you through. I just implemented this on my demo server, you can have a look at list named Previous month orders only: When I run this list today (2020-06-02), I want to remove orders that: were created before the start of previous month (2020-05-01) or were created after the start of current month (2020-06-01) So I will need to add two new conditions. Let's start with the second one, because it's easier Filter out order created after the start of current month In my expressions, I will use field runtime.timestamp that contains current time. I need only a year and month parts of this date, though. To extract it, I can use function formatDate. I will use format 'Y-m' which will return year and month: formatDate('Y-m', runtime.timestamp) this will return string 2020-06 This is almost what I want. All I need to do is append static string to it: formatDate('Y-m', runtime.timestamp) + '-01 00:00:00' this will return string 2020-06-01 00:00:00 Which is the start of current month. Now, I can use this expression to include only orders created before this date. The condition will look like this: orders.created < toDate('Y-m-d H:i:s', formatDate('Y-m', runtime.timestamp) + '-01 00:00:00') I had to convert string back to datetime using toDate function, and then I can finally compare it with order creation date Filter out orders created before the start of previous month Second condition will be more complicated, because we need to figure out previous month To do this, I will once again use formatDate function, but this time I will use format 'm' to extract month part only. As of today, this format would return string '06'. I will convert string to number 6, and then substract 1: toNumber(formatDate('m', runtime.timestamp)) - 1 When I run this expression on 2020-06-02, it will return number 5, corresponding to previous month. However, if I run it on 2020-01-20, the result would be 0. That's not what I want, I need 12. To fix this, I can use simple if expression: if(formatDate('m', runtime.timestamp) == '01', 12, toNumber(formatDate('m', runtime.timestamp)) - 1) The if function takes three parameters. The first parameter must evaluate to true/false. If it evaluates to true, then the result of if function is the second parameter. If it evaluates to false, the result is third parameter. In our case -- if month part is '01' (January), the previous month is 12, otherwise the previous month is (current month - 1) Now we know the month part. We also need to figure what year is previous month in. To do so, I will use formatDate function with 'Y' format: if(formatDate('m', runtime.timestamp) = '01', toNumber(formatDate('Y', runtime.timestamp))-1, toNumber(formatDate('Y', runtime.timestamp))) This expression reads as: if current month is January, then return current year - 1, otherwise return current year. Now that we know year and month part, we can construct start of previous month. I can simply concatenate these expressions together: if(formatDate('m', runtime.timestamp) = '01', toNumber(formatDate('Y', runtime.timestamp))-1, toNumber(formatDate('Y', runtime.timestamp))) + '-' + if(formatDate('m', runtime.timestamp) == '01', 12, toNumber(formatDate('m', runtime.timestamp)) - 1) + '-01 00:00:00' The result of this expression is 2020-5-01 00:00:00 Now I can use this expression to finally create a condition to include only orders created after this date: orders.created >= toDate('Y-m-d H:i:s', if(formatDate('m', runtime.timestamp) = '01', toNumber(formatDate('Y', runtime.timestamp))-1, toNumber(formatDate('Y', runtime.timestamp))) + '-' + if(formatDate('m', runtime.timestamp) == '01', 12, toNumber(formatDate('m', runtime.timestamp)) - 1) + '-01 00:00:00') It's a little bit complicated, but fortunately it can be done.

Sure, you can add whatever you need to your product.tpl. Your snippet is wrong, though -- there is no opening <a href="..."> tag for the closing </a>

Also, I have a module named consistency checks . Maybe it will find the inconsistencies in your db

Hard to tell, but it's definitely some data consistency issue. Maybe there are no records in tb_category_product table? To help more, I would need access to your back office, or phpmyadmin.

It's possible that the ntree index is broken. Category table contains columns nleft, nright, and level_depth. These columns are useful for quickly obtaining only a part of the category tree (like all subcategories, or all parent categories query). But sometimes the information in these columns is out of sync with id_category / id_parent, and needs to be regenerated. To regenerate entire category ntree, you can simply create a new category, and then delete it.

@pendulum that's quite a rant, really. The fact that you don't want, or need, these fields doesn't mean others don't need them. For example, if you were selling alcoholic beverages online, I'm sure you would have to collect DOB information. Regarding newsletter subscription - if you don't want to collect newsletter information, well don't collect it. I understand the sentiment behind this, but the truth is that email marketing works. For many stores, it's a major revenue channel. And many merchants depend on it. I agree that these don't need to be in the core. They should have been implemented by a dedicated modules, for only those merchants that needs them. But they are already in the core. And thus, it's not easy to remove them. That would mean compatibility breaking change. There are many third party modules that utilize information stored in these fields. If we removed them from the core, we would break these modules. And then there would be a crowd of angry merchants complaining about this *fcking* platform, like you do now. The good news is, these are not required fields. It's very easy to remove them from the template, it's just a delete in a template.

In my experience, the biggest problem with sending data to fb/google is data quality. Merchants are looking for a 'one click' solution, but it does not exists. It's a lot of (manual) work to build a good enough dataset. Facebook and google expects a lot of information, and they complain if you don't provide it. For example, the xml should contain <g:google_product_category> element, that should contain product category -- from google taxonomy list. This information can't be found anywhere in thirtybees database, of course. There needs to be a mechanism to map your categories to google category list. And somebody have to actually enter this mapping to the system. For some products, fb requires that you provide additional information, like gender or target age. Again, that's not something that is readily available in thirtybees database. xml must contain <gtin> info. In tb, this an be either UPC code, ISBN code, or EAN code. If you don't enter these information to your products, google will reject the xml. ... and more It's just not possible to install a module and expect that it will magically figure out all these information out of thin air. These information needs to be manually entered somewhere. My module allows entering this information, because it support custom fields. But merchant still need to fill in the data.

Move this line to your required position. Note that it will move content of all modules that use displayProductButtons hook.

There's no need to be sassy. Unfortunately, this is how customization works. In templates, you can do small changes, mostly related to design. But it's not possible to display new data, simply because template doesn't have them. There must be some piece of code that extracts this data from database or other source, pre-process them to appropriate format, and pass them to template. This is controller's job. So, if the customization request asks for new set of data to be displayed, then controller needs to be involved. You can either edit core controllers (which is a big no-no). Or you can create a new controller inside a new module, and use hooks to display content where you need it. I understand that regular merchant can't do this. It's very technical. That's why professional developers exists.

The warning you got from mailalerts was because your configuration for the module contained empty value. But it was fixed when you resaved mailalerts configuration. Anyway, this issue should be fixed. Tracked here: https://github.com/thirtybees/mailalerts/issues/9 Well, now that you have the mailalerts module reinstalled, I believe it will work once again. Let us know if this did not help