datakick

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

What tb version are you running on? > I did switch themes last week, but switched it back. I believe this is the culprit. Switching themes can unregister hooks for modules that are mentioned in config.xml. This is already fixed in bleeding edge, but if you are on 1.1.0 or older, this behaviour is still there. Anyway, uninstall and reinstall module. That will fix the hooks. Regarding your other problem -- you have incomplete installation - file admin-dev/themes/default/template/controllers/logs/employee_field.tpl is missing. Fix the installation using core updater.

You see, these are the information that are very relevant for troubleshooting. Now we know that we are talking about mailalerts module. So that should be the first thing to check. Is the module enabled? Is the enabled on all devices, and not only on desktop? check Advanced parameters > Performance > Disable non thirty bees modules Are all module hooks hooked correctly? Try to reset it Also, look into Advanced parameters > Logs, newer versions of thirtybees logs missing email templates there Interesting is also the fact that this worked before. You must have changed something recently. Do you remember changing anything, for example switching themes, or installing new module?

That's not core functionality. Core does not notify merchants by email. You probably had mailalerts module installed

What email are you talking about? Core only sends confirmation email to the customer, is this one you are talking about?

Thanks for that, I really appreciate this. In current *security first* world it's very difficult to build distributed api solutions. Anyway, I will probably implement the server-to-server api communication as well, and use browser-to-server only as a fallback.

Thanks for reporting this. The 'Check for updates' functionality works fine for me, though. The problem is probably with your browser. Most likely you have installed some plugin that prevents tracking. Check for updates functionality uses ajax call from browser to my api server, and some plugins can interpret this as an ads or analytics tracking attempt, and therefore block it. That's pretty aggressive. Alternative would be to use server-to-server calls (curl). But that's not reliable as well, because many hosting providers block outgoing connections for security reasons by default.

I have released new version 0.8.0 This version fixes one serious bug from 0.7.0 regarding payment redirection. If any one of you is using 0.7.0, please install the new version. Other than fixing this bug, there is also a new functionality implemented. As you might know, chex has custom fields support since version 0.5.0. But this support was very limited, because entered data were not stored in the database. That meant that the use case was limited for *required checkbox* fields only. In this new version, I've added persistence support. All informations entered by your customers will be saved to database. At the moment there is no UI option to see these saved values, I'll implement that in the next version. But at least data are now stored, and you can access them using direct sql.

Hi, unfortunately mass update does not support changing associations between records, so it's not possible to assign category to product this way. Mass updates can only update record fields. It's true that product record has 'categories' field, but this is virtual/read only field for export purpose only. The only way to modify associations using datakick is via import functionality.

The code we have just fixed is in the error execution branch (unfortunately). Which means that either line if (isset($this->context->cookie->oasl_data)) or lines // Extract the data. $data = json_decode($this->context->cookie->oasl_data, true); // Check data format. if (is_array($data)) evaluated to false. This is not a technical issue, but business-logic issue. This variable is either not set, or contains invalid content. Either way, you should definitely report this to the module developer. This won't be easy to fix, without deep knowledge of module design and data flow.

Your php must be using old gersion of php file, then. https://stackoverflow.com/questions/43170746/when-does-phps-opcache-re-parse-a-file Try to restart your server, or clear opcache

First of all, you should enable debug mode when you are debugging the site 🙂 You can use my 'Advanced debug mode' module that will make sure that you will always use debug mode, yet your customers will use normal mode. Anyway, back to the error at hand - your file is missing ending brackets } Take original file, find line 161: Tools::redirect(); and replace it with these three lines: $back = trim(Tools::getValue('back')); $back = (!empty($back) ? $back : oneall_social_login_tools::get_current_url()); Tools::redirect($back); Don't change anything else.

It can't be the same error. Even if the $back variable contain null, it is still value that is being passed to the Tools::redirect method. So it's not possible for this to throw Too few arguments to function error.

@AndyC, you didn't replace the like 161 with the new content. The file should end like this: // We could not extract the data. if ($have_error) { $back = trim(Tools::getValue('back')); $back = (!empty($back) ? $back : oneall_social_login_tools::get_current_url()); Tools::redirect($back); }

please attach the modified register.php file

The official W3C XHTML specification, Section B. "Element Prohibitions", states that: "form must not contain other form elements." You have moved form inside another form. Browser will just silently (or maybe with some warnings in js console) ignore the form element, and merge the <input> elements into the parent <form>. When you click on the submit button, it is the parent form (add to cart form) that is being submitted, not the customization form. I would personally just ignore this for the moment. I would remove the 'save' button and focused on auto-submit of customization. This can be done entirely using javascript. If you do this via js only, then you can easily control what information will be submitted, and how to extract them from the page dom.