datakick

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

You can use my Datakick module, as it has mass update functionality. It will allow you to change tax rule id of all (or subset) your products

New version 0.7.0 - Webhooks support Hi everyone. I've just released a new version that brings new action: Execute Webhook A webhook (also called a web callback or HTTP push API) is a mechanism that application can use to notify other web applications about some events. This action plays very nicely with conseqs. With this action you can create advanced automations. For example: you can send notification to your Slack channel when new order has been placed you can automatically add customer's email address to your mailchimp list when they register when new order is placed, you can notify Datakick module and it will generate xml/csv file with this order information and much more...

Unfortunately conseqs can't detect object models declared by other modules. Thirtybees does not have any registry of these objects

Thirtybees template are rendered in two phases. First, the content itself is rendered (for example product.tpl file), using one set of smarty variables. Then the layout is rendered, using content from the first phase (stored in template smarty variable). This second phase uses slightly different set of smarty variables. After all this is done, then some black magic is performed on the string output. Like replacing some placeholders, injecting javascript code to the right place, etc. This post-processing is what causes your problem. In layout phase, there's special smarty variable 'js_def' that contains placeholder. In post-processing phase, thirtybees replace this placeholder with actual javascript content. When you run {debug} in this phase, then the debug console contains this placeholder as well, and thirtybees will replace it in this javascript code as well, without proper escaping. You can fix it by editing debug.tpl file -- check if variable is named 'js_def', and if it is, then don't render it. Please crate a pull request for your fix

Yes, this is a bug. I've filed it into gihub so it won't be forgotten: https://github.com/thirtybees/thirtybees/issues/1191

I'm not sure if I understand correctly the question. Do you want to have multistore for different domains? If that's the case, then sure -- you need to set up your DNS so both domains point to the same IP address / same server, and then set up multistore urls correctly in your admin. If unsure how to do that, contact your hosting provider, they will be able to help

How does your Authorized modules look for the group you edited? I bet all modules are un-toggled. It should look like these:

If you don't collect card info on your website, then it's not necessary to be PCI compliant. If you, however, have some card info input form on your site, then you should be. For example, stripe module let you include card form directly on your checkout page. It's better to disable this option and just redirect your customers to stripe website.

On a related note Thirtybees 1.1.0 is very strict regarding this config.xml hook settings. Unfortunately, many themes comes with incorrect config file. These themes installed (somewhat) correctly on ps16. But that was only because the installation process in 1.6 was buggy as well - two wrongs produced somewhat ok result. Thirtybees fixed these bugs in theme installation. The side effect of this 'fix' was that some module did not install correctly anymore. Because it's hard, or next to impossible, to force all theme developers to fix their config files, we have related the requirements a bit. In bleeding edge, the theme with such incorrect config file will install, but it will produce quite a lot of warnings. The xml file for that theme should be fixed.

I believe that you have installed some theme with incorrect xml config file. When you install theme, thirtybees will unhook all theme related module hooks (those that starts with display...), and then re-hook them back according to specification in config xml file. Config xml is the only source of truth here. If the module is not mentioned in theme config file, it will not display in the new theme by default.

Also, make sure you select Version to compare = 1.1.x, and not 1.0.x. Unfortunately, 1.0.x is the default for new installations.

@toplakd could you please try update your test instance? Bleeding edge contains new version of smarty lib, so there might be some issues with it. I didn't encountered any, though.

That is strange. I have latest bleeding edge installed on both my development and production server, and it works without any issues.

There are no stable versions, there are only named versions, I'm afraid. Version 1.1.0 is just an arbitrary commit that was picked to be named version just because it was a nice idea to have a new version released. It was tested, of course. But not extensively -- unfortunately there are not enough resources for that. There is no dedicated QA team. So far, the emphasis of thirty bees developers was not on the new features (we believe the system is complete, if not over-bloated), but on a code maintenance and bug fixing. This usually means that commits are very focused and targeted. There is usually minimal disruption, or potential for bug injections. And if there is a new bug introduces, it is usually fixed right away (these have highest priority), and the bleeding edge is soon fixed. This is why I always recommend using latest bleeding edge -- it should be more bug-free then any previous named version. And the best thing is -- it's very cheap to test the new version. If you don't have any core modifications (you should never have these), then it's just a single click of the mouse in core updater. You should then thoroughly test your store. If it doesn't work, then it's just as easy to revert. In that case, please report this new issue on the github. If you use magic words like Regression or Injection, it might get magically fixed within days. And then you can try again.

You will have to look into your web server error log, and to log in thirtybees/logs directory. There will probably be some hints about what's wrong.

I'm sorry, this is not the right solution. It silently expects that only one module will provide tab content. This is often not true, there can be many modules each of them wanting to display their own tab. Your code would group content from all these modules under one tab, instead of creating separate tabs for all of them. Also, you the tab names are ignored. Just saying 🙂

Yes, as long as you run on a required stack, you can start selling out of the box. Of course, you will soon find out many things you will want to modify, theme wise. And then you will have some custom requirements, hence the modules and/or custom development. And once you install a lot of them (especially modules with overrides), things will start to fall apart, and you'll need to hire some support agency that will help you keep things tidy. But that's normal on every platform, I guess.

Neither community theme, nor niara theme, supports tabs on product page. It's not hard to do, but I guess the theme author liked all-in-page better then tabbed content