Jump to content
thirty bees forum

datakick

Administrators
  • Posts

    3,132
  • Joined

  • Last visited

  • Days Won

    492

Posts posted by datakick

  1. That's not error from datakick module, but from cronjob module.

    Looks like you didn't updated that module correctly - column 'minute' is missing from ps_cronjobs table. I suggest you re-install that module to fix this problem, or manually add the column to db table. Then reinstall datakick module again

  2. Parameters behind # are for client use only. Request to the server never contains those parameters, server never sees them and can't react to them.

    When you open urls

    https://www.example.com/en/products/84/sample-product#/72-size-large

    or

    https://www.example.com/en/products/84/sample-product#/whatever

    your server receive the very same request - https://www.example.com/en/products/84/sample-product

    It does not know what combination you are requesting. Javascript will later parse the hash parameters, and will modify the product page to display the wanted combination if it's found. This also means that initial page render shows different combination, and only a few milliseconds later the page is 'adjusted'

    When you provide ?combination=xxx parameter, server knows upfront what you want to display, and can returns page with combination already selected (if your theme supports this, of course). The page already contains correct pricing information, product name, reference code etc -- this is important for web crawlers.

    This means that you need to provide urls with standard query parameters (after ?) to google

    • Like 2
  3. I was mistaken, niara do not hide images not associated with selected combination. It only shows combination cover image.

    However, it's not complicated to implement this. You need to modify file themes/niara/js/product.js - search for function refreshProductImages and add hiding/showing logic for images

    • Like 1
  4. 9 hours ago, jnsgioia said:

    I did that and it did not make any difference.  All images still show.

    What theme do you use?

    This is, ultimately, theme responsibility. Core only provides information about images and their associations with combinations to theme. What theme decides to do with those informations is up to theme. 

    I believe that standard thirty bees themes do implement this image hiding. But only if the combination have at least one image associated

  5. The standard template that datakick module installs do not contain shipping weight by default.

    You can very easily add it, though.

    GMC documentation https://support.google.com/merchants/answer/6324503?hl=en tells us that they are looking for element like this

    <g:shipping_weight>3 kg</g:shipping_weight> 

    So let's edit the template, and add this element under <entry> node

    image.thumb.png.ff054168f02d878ae1b9b34febc0c5f9.png

    To get data in correct format, you need to use the expression 

    product.packageWeight + " kg"

    Note that you need to do this twice if you are using GMC template for combinations, as there are two <entry> nodes in template, one for products without combinations, one for products with combination. In this case, you will need to use different expression in second node:

    combination.packageWeight + " kg"

    You can download this template:  gmc-with-weight.json and install it into your datakick module, as an inspiration

     

    • Like 1
    • Thanks 2
  6. I don't think it's a bug in the system. I have no problems creating customer accounts with that name, or creating orders.

    My guess is that your database charset / collation is not correct.

    Use core updater to check if your database tables use correct character set and collation. It should be CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci

  7. I've added the option to set columns as hidden by default. When you create list column, you can pass 'hidden' => true, and thirtybees will not show it by default. Here's example:

    https://github.com/thirtybees/thirtybees/blob/f27320165d9e788af9f702af547adaaed6e0db90/controllers/admin/AdminOrdersController.php#L179

    Once we implement list column customization, we will be able to show those default hidden columns, hide columns that are displayed by default, or even reorder columns in the list.

    • Like 2
  8. Yeah, that's unfortunate. It's because there is actually no type column in product table. Product type is determined on thy fly from other product properties. For pack, there must be pack items in pack table.

    So, you have to switch to 'Pack combination' type AND then, before you save product, go to Combination tab and assign pack content to at least one combination. That will lock it in

  9. Thanks everyone for testing. I've created the issues for those problems, and will make sure they are addressed before we merge this into bleeding edge.

    As we found out, the solution we implemented before was not good enough for all use cases. The virtual/dynamic attributes are fine in most cases, but sometimes we need even more flexibility. So we implemented yet another enhancement in this area -- full-fledged packs per combination.

    You can now choose between two different versions of packs 

    • Pack of existing products -- original implementation, when pack is defined on product lavel. You can use virtual/dynamic attributes here to tweak pack content using dynamic product attributes, as described in this thread above
    • Pack of existing products - combinations -- new functionality. When you select this, you won't be able to define pack on product level, but you will have to define packs for every combination separately. This gives you great flexibility, as your combinations can have totally different/independent pack items. But obviously, it will be more complicated to set up, as you need to define pack content for every and each combinations. So choose this only when appropriate

    image.thumb.png.549ca55f5a7d97f5fcba08b9b6c3217e.png 

     

    Pack content on combination level:

    image.thumb.png.947c5178de7dac0f6b655cc30ab8ae88.png

    This new functionality is in pack-combinations branch.

    If you can, please help us with testing once again. 

     

    • Like 1
  10. Thanks for testing

    14 hours ago, wakabayashi said:

    I am now playing around with this... What is the technique behind it, where are the filter values saved? In cookies? 

    Yes, so far the values are saved in cookies. However, there is now an abstraction (ListViewStorage interface) that will make it possible to save filter values differently in the future. It's a todo task that I would like to implement soon. With this in place, cookies will be much smaller, and we will be able to implement additional features like saved filter presets. I think that will make this quite useful

    14 hours ago, wakabayashi said:

    With a pretty basic list of my module, it seems to work fine. With a very complex list, I get the following...

    Thanks for bug report. I believe I have fixed this - could you please re-test on latest version of this branch? If you still get the error, please send me a controller class, so I can figure out what is wrong.

    • Thanks 1
  11. 22 minutes ago, insecta said:

    I see that the coreupdater it's not compatible with php 5.6 because it use ?? (coalesce), that it's not supported, but I can't upgrade php for the errors, so I'm in a loop

    I've just released a new version 1.6.12 of coreupdater that should fix this php5.6 compatibility issue.

  12. 1 hour ago, musicmaster said:

    Here is the discussion on the Smarty Github: https://github.com/smarty-php/smarty/discussions/967

    Thanks, interesting read.

    At least for smarty v5 there is a dirty fix available that will not require much work. That's good to know.

    Unfortunately this fix is not available for smarty 4.4.x, so we will have to skip those and update straight to smarty v5. And there are many breaking changes related to that update, so it won't be doing that anytime soon.

  13. 1 minute ago, Yabber said:

    On github I saw that to smarty version 4.5.5 developer from prestashop added support for PHP 8.4
    https://github.com/smarty-php/smarty/releases

    Unfortunately it won't be easy to upgrade smarty to newer versions easily.

    New versions of smarty raises a lot of new deprecation warnings when templates call php methods directly. We are now required to register all methods that are allowed to be called from smarty template. As you can imagine, that's something absolutely impossible for system like thirtybees/prestashop -- we simply don't have that information.

    For example, if some module template contains code like this:

    {if Configuration::get('PS_INVOICE')}
    	<span>...</span>
    {/if}

    we would have to tell smarty engine that the method Configuration::get exists and can be called.  

    In the near future, using that template without registering the method would cause runtime error.

    Because we are using templates from third party modules and themes, we simply don't know what methods are used. The only potential solution for us is to parse templates to collect list of all used methods so we could register them before template is used.

    While the parsing can be done only once (when template source changes), the registration of methods needs to be done on every render. That will cause quite a big performance impact - we need to load the info from somewhere and pass it to smarty engine.

    I don't understand why this change has been introduced, and I'm very unhappy about that. 

    We will either have to keep using smarty 4.4.1 forever (which is not possible due to new php versions not supporting it).

    Or we will have to invest days or weeks of work to implement that stupid registration, just to get to the same point we are now.

    • Like 1
    • Sad 1
  14. The core is not yet php8.4 ready. We already fixes few issues, but there are still some to iron out.

    There is nothing braking, though - just a lot of new deprecation warnings, mostly related to "Implicitly nullable parameter types". PHP8.4 now complains when parameter with default null value is not marked so. All methods and function that look like

    public function func(string $test = null)

    must now have slightly different signature:

    public function func(?string $test = null)

    It's fairy easy to fix these warnings. There are even an automated scripts to do that across entire codebase. But obviously, we can't fix third party modules.

    I'm also a little bit worried about method overrides. I'm not sure how well PHP will take if the overridden method has slightly different signature. 

    • Thanks 1
×
×
  • Create New...