Jump to content

Welcome, Guest!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

Leaderboard


Popular Content

Showing content with the highest reputation since 10/15/2021 in Posts

  1. 3 points
    A little later than expected but finally it is here. Thirty bees version 1.3. This is a major release and unless security updates are needed we expect this version to be there for the long term. Next major version 1.4 will be released in approximately 6 months. What is added in functionality in thirty bees 1.3? Please check carefully if you need to change something like translate or updating mail templates. We have added: merge accounts of users (old + new email can be merged) - Passwords will not be sent by email but can be changed by clicking the recovery link in the email (update template if you customised it) coreupdater - new version that tracks errors so we can follow-up on upgrade issues work queue - mechanism to execute work jobs asynchronously in order to speed up request processing theme extensions - ability to extend themes, which allows us to introduce new front office features like new password reset work on php8 compatibility - module installation overhaul (1.6 still supported) product page tabs permissions - one can give for example a translator only access to certain parts Also note that version 1.3 is the last version that supports php 5.6. If your store still runs on this old php version, please update soon. If you fail to do so, you wonโ€™t be able to update to the next major releases. We have to introduce new perks for super awesome backers and higher! Super Awesome Backer: We aim to view your post within a few days and will give you an answer and direction to look in to the problem so you can try solving it yourself. (Mention @datakick in your post) Bronze Sponsor We aim to view your post within a 3 days, and provide a concrete solution. (Mention @datakick in your post) Silver Sponsor We aim to view your post within a 48 hours, and provide a solution that you can directly implement. (Send a forum message to @datakick) Gold Sponsor We aim to view your post within a 24 hours, and provide a solution that you can directly implement. (Send a forum message to @datakick) How to use this service? Well you have to sign up as backer and after the first month we will start fulfill the backers advantages. If you then post a topic just send the topic link in a privet message to @datakick he will then take care of you! If you think we can do this even better, just let us know your ideas and we will try to enhance the backers program. You can post your topic in a regular forum or in the supporters forum. And as always: Donโ€™t forget to join as a backer! Small or big we enjoy the beer we can buy from it. You can become a supporter for as little as $5 per month. And when you tip in more we can make nice enhancements to thirty bees.
  2. 2 points
    I believe the easiest solution for you is to just tall your store to use old prefix. To do that, edit file /config/settings.inc.php and change value for define('_DB_PREFIX_', 'tb_'); for example to define('_DB_PREFIX_', 'ps_'); Then go to core updater and check database differences. If there are some critical changes, apply fix. Please backup your database before. If this prefix changing is not the right approach for you, for some reason, you will have to copy every table independedly. Use sql like this for every table (ps_product is source, tb_product is target) truncate tb_product; insert into tb_product select * from ps_product; If the columns or their position are different, you will have to enumerate all fields as well: insert into tb_product(id_product, id_supplier, id_manufacturer,.....) select id_product, id_supplier, id_manufacturer,..... from ps_product; Very tedious task
  3. 1 point
    There are no 'known' problems with core updater. All reported problems were fixed and new versions were released. You can download the latest version here. @jmeca did you try my suggestion about updating /tools/cacert.pem ? That should fix your certificate validation issues, and you should be able to update the store.
  4. 1 point
    You may want to try this module: https://www.prestashop.com/forums/topic/47173-module-list-of-customer-out-of-stock-registrations/page/2/?tab=comments#comment-3277907
  5. 1 point
    The issue I run most often into is the inability to attach files with the customer service messages. Probably I am biased because I sell software. But I can imagine that other people will find it handy too for sending manuals, product previews, etc.
  6. 1 point
    3.3.0 - 10/15/2021 Complete redesign of the generation of emails sent to carriers to facilitate the management of translations with the native system of PrestaShop Improvement of the FAQ with the precise name of the directory of the active template on the store Display of language folders in the FAQ in alphabetical order Added a configuration option for each carrier to display a message when an email is sent to the carrier 3.2.0 - 10/11/2021 Code rewriting following the redesign of the Orders page in Symfony in PrestaShop 1.7
  7. 1 point
    The ajax problem will be, most likely, caused by mixing http and https. Browser might block ajax requests from http to https. Make sure you are logged in to your back office using https:// protocol, and then try update again.
  8. 1 point
    Looks like this commit is the culprit: https://github.com/thirtybees/niara/commit/6abc6b7e555caadb48b02e662ffd8da105a927f8#diff-25beb89b157fe43848421e7b4cf456c7fa1a603879047d3c1e5c636aa5dff62e For some reason the working templates were overwritten with this mess. Probably not an intention. I will revert this commit
  9. 1 point
    Yes, that's the advanced functionality that we plan to put back there in the future, very well hidden so that nobody will use it ๐Ÿ˜‰
  10. 1 point
    Of course I can ask them to look into database ๐Ÿ™‚ But fortunately I won't have to
  11. 1 point
    Why? For people that will use Stable releases this is not an issue. The revisions will always match official release tags, such as 1.3.0 or 1.2.0. If you are using bleeding edge, then you will see current exact git commit. This information for machines, not for humans. Revision is precise and it nicely correlates with information on github. I understand that from human point of view, it's nicer to see 1.4.134 instead of d601a7dfa69025341ea598f558885b6cbbd7b7b4. However, nobody would be able to figure out what exactly is part of version 1.4.134, or what are the differences between 1.3.0 and 1.4.134, simply because 1.4.134 would not tracked in repository. With revisions, we can look at github and see it all. What is part of this version? https://github.com/thirtybees/thirtybees/tree/d601a7dfa69025341ea598f558885b6cbbd7b7b4 What are the differences between 1.3.0 and current bleeding edge? https://github.com/thirtybees/thirtybees/compare/1.3.0...d601a7dfa69025341ea598f558885b6cbbd7b7b4
  12. 1 point
    I believe you were on some bleeding edge version before? If that's the case, then rest assured -- this is the one-time issue only. Next update will not be affected. When updating to bleeding edge we didn't actually saved exact git revision that was being used. In your store the only available information was that this is some variant of 1.2.0. Not very useful. During update, core updater asked server for a fingerprints of files for version '1.2.0', and checks it agains files on your server. Of course, every files that were modified between 1.2.0 and the bleeding edge version you have on your store will have different fingerprint, and so they will be considered modified. The new core updater fixes this issue -- we now define new constant _TB_REVISION_ that points to exact git revision or tag. During update, core updater will ask for fingerprints of files for this exact revision.
  13. 1 point
    Updating indeed allowed it to go further. Thank you. The database software is MariaDB 10.4.8
  14. 1 point
    From server log I can see that some clients requests file list over and over again. Looks like the client fails to store the file list to cache. At least thats the only explanation I could came with. This is (hopefully) fixed in latest version of the module. Are you using 1.4.3? Edit: From your log it's evident you are using 1.4.0. Please update core updater module. BTW, what mysql version are you using?
  15. 1 point
  16. 1 point
    Install new version of core updater 1.4.3 and try again.
  17. 1 point
  18. 1 point
    It looks like DHL has switched to a new API and maybe dropped support for older WSDL if you look in there main wsdl page you will see: <wsdl:documentation> NOTICE: This WSDL is valid for implementations that are in production prior to 14th March 2021. Please note that there is a new WSDL as part of the latest MyDHL API Developer guide. Please contact your local DHL IT Contact. </wsdl:documentation> i am not using dhl so I can't tell much. Good luck
  19. 1 point
    The root cause is here: /home/veganlin/public_html/classes/Mail.php(293): Swift_Mime_SimpleMessage->addBcc(NULL) The system is adding null BCC address. Now, the question is why. Do you have some module that hooks to hook actionEmailSendBefore? check BCC all mails to configuration option in Advanced Parameters > Emails can you PM me access to your back office?
  20. 1 point
    Disable module mailalerts and try again. If it works, enable it again, and fix its configuration.
  21. 1 point
    The root cause is well hidden... this module does excellent job hiding everything important from everybody Edit file modules/stripe/classes/PaymentProcessor.php, find line this->addError($this->l('Failed to validate order'), (string)$e); and change it to look like this: d("$e"); $this->addError($this->l('Failed to validate order'), (string)$e); The d("$e") should display additional information when error happen. Hopefully we can use this info to figure out what's actually wrong
  22. 1 point
    Looks like when you updated module, its configuration was reset, and it's back in testing mode. The payment intent is stored in cookie, and is no longer valid. Please check module configuration and switch it to live mode, if that's what you are testing. Also, clear browser cache / cookies.
  23. 1 point
    You may have hit the nail on the head. I will change the rounding to each line and see if that make a diffference. Thanks
  24. 1 point
    First thoughts: Looking good - a great start 1) It does not interfere with the multiple feature module i have 2) works with Advanced search 4 and block layered navigation 3) I did not need to change the table indiex so guess the module I have had already done that 4) Works with store manager Suggestions, while I understand you do not want to 'copy' the multiple features module perhaps what it does will help tidy things up 1) Do you really need to indicate which features are allowed multiple features? If all were allowed then there would be no need for extra columns in the features table. So make it so all are multiple value then just not use when you don't need to for each individual feature 2) We have lots of features so finding them is tricky. Lot's of scroll and ctrl / select to choose. Not easy to see what is selected: The current module has a search feature (narrows down the list as you type and also shows the list of currently selected ones to the side 3) With lots of features the front looks not good Where as the current module sepearates the multiple features with a comma (Seperator symbol can be changed in module) rather than line break making it much easier to see 4) Possibly need a sort by position rather than numerical / alpabetical / index Overall a great start - well done. Now all we need is Block Layered Navigation to allow multiple selection and perhaps ranges (sliders) and all will be near perfect ๐Ÿ˜‰
  25. 1 point
    I personally believe that product miniatures should NOT have rich content metadata. Especially when you display them on product page - for example if you have list of related products, "customer also bought", or "other products from this category". In this situation, google has hard time to understand what the page is about. From google's perspective, the product page contains multiple products. Sure, one of them is primary, but how should google know this? The primary goal of google is to understand and interpret the page. Adding too much noise to the page is not helping this, I think. I strongly believe that, in this case, less is more. I have it implemented like that on my website, and I'm very happy with it. I have zero warnings/errors in search console, and more importantly - my rich data are displayed correctly in search page result.
  26. 1 point
    You can't. It's just not possible to include reviews metadata if you don't have any reviews. Google search console is an idiot in this case. Simply ignore these warnings.
  27. 1 point
    That is hardly anything that the normal TB user will ever understand.
  28. 1 point
    @devnix said in Clear Demo Data: Wouldn't be AWESOME to be able of running the installer without inserting demo data? :smile: It's what I ask for too. Maybe Demo Data is useful for testing the system. But at least there should be an option to disable it, while doing the installation.
  29. 1 point
    At least a choise of adding them or dont. Was it not like that long ago?
  30. 1 point
    Wouldn't be AWESOME to be able of running the installer without inserting demo data? :smile:
ร—
ร—
  • Create New...