datakick

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.

It's not fixed. Edit file controllers/front/register and replace line 161 with this. Also, report this to the module author, they should fix it.

Well, obviously the 'corrected' version is not fixed :) Could you please share github repo, I'll have a look

This is exactly the same problem as the one you have reported in the first post. The problem originated here: modules/oneallsociallogin/controllers/front/register.php:161