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 12/01/2019 in Posts

  1. 5 points
    It was Thanksgiving here in the U.S. thursday. As I'm getting back to work, I just wanted to let you all know know how thankful I am for this community in helping to keep TB a top notch store front tool. Especially to all they folks writing code on the backend and responding to all of us business level admins to assist. I and my business really appreciate it.
  2. 2 points
    New version of coreupdater module was released yesterday, and it contains one new functionality I'd like to talk about a little bit: Database schema comparator and migration What does it mean? It means that core updater will now look into php codebase and extract metadata from object model classes (like Product, Customer, or Order). These metadata describes exactly how database should look like -- what database tables should exists, what columns should they contain. It describes primary or foreign keys, column type, default values, collations, etc.. Core updater will use these collected information and compare them against your actual database schema. And if there are some differences, it will report them. And it will also allow you to fix them. This essentially makes php codebase single source of truth in regard to database structure. When you install your system from scratch you shouldn't see any database differences. But those of you that are running your thirtybees system for a long time now will see a lot of differences. It could happen for many reasons we developers tend to forget about implementing respective sql migration when we change php code when we actually implement such migration script, it can contain errors. After all, php devs aren't usually mysql experts also, some modules can change database schema for their needs Why do these differences matter so much? That's because PHP code operates under some assumptions. For example, it expects that order reference code can contain 11 characters. The php code that generates unique reference code for order can fail terribly if the actual database column can store only 10 characters. The error can occur right there during reference code generation (then it's easy to find). But it can happen much later. With these data consistency issues it's hard to figure out how they happend, and how to fix them. By aligning your database structure with expected database schema, you are much closer to (my favourite) vanilla thirtybees installation. Thirtybees core code will run more smoothly in such environment. I'm not saying it will not run OK on modified database schema, just that there can be some very strange behaviour sometimes. How to use this new tool Please be aware this is experimental feature, and requires some database knowledge. It's not very user friendly. And some messages will probably scare you -- but that's intended behaviour. It is very powerfull tool, but we should use it very carefully. There is new tab named Database schema (for developers). This tab will display you all (relevant) database differences. Note that thirtybees core needs to support this functionality. At the moment, this is supported in bleeding edge only. In current version 1.1.0 or older, this tab will simply inform you that the database comparison functionality is not supported. So, if you want to test this new functionality, please migrated to bleeding edge. This is how the list of database differences looks like. You should review all differences, starting with those marked as critical While it says critical, the reality is usually not so grim. Obvisouly, missing columns or tables are indeed very serious issues, and you should fix these immediately. But different column type is not such a big deal. All database differences can be fixed. You can simply click on Apply fix button to adjust database. Please make sure you understand what this means!!! Some database differences can be actually valid and wanted. For example, some module might have changed database structure of core table in order to provide some additional functionality. *Fixing* this table back to original state might break the module. One such module is *Multiple feature values* -- this module drops unique key for one core database table in order to actually save multiple feature values into the database. If unsure, please ask here -- it also gives us opportunity to learn more about different type of customizations. And some video:
  3. 2 points
    Hi, Another forum where a person arrives with his problem, asks for help, finds the solution on his own, deletes his question and asks to delete his Topic. Yet, this person comes to the forum to find answers to his questions, but if everyone asked to delete his Topic, what would become of a forum? 😢
  4. 1 point
    Another recommend for the Chex Module here AndyC. We are still using the 'old' Warehouse theme and aimed at UK only clients. After numerous problems we dropped Paypal. However, we can certainly recommend 'Stripe' for the payment processing. The combimation of Chex and Stripe is a winner for us.
  5. 1 point
    This module shows basically how to extend a controller list from a module: https://github.com/thirtybees/orderlistcarriers/blob/master/orderlistcarriers.php
  6. 1 point
    Hola! instalé el modulo nuevo de STRIPE SCA y no me funciona tengo la version 1.8 con el módulo de onepage checkout. Ojala me pudieran echar una mano Gracias Selene
  7. 1 point
    We regularly have such complaints too. First of all, I never know, if it's on our system or on the customer. Sometimes customers are using super old devices or harmful browser extension. Sometimes also customers are just "too dumb" (sorry for the words) to place an order. Of course we can critize, that things are too complex then. But to be concrete. When was bleeding edge last updated? This issue can prevent customers from odering (happened here multiple times before the fix): https://github.com/thirtybees/thirtybees/issues/1056
  8. 1 point
    That's sad. But I am not totally suprised, tbh. A few years ago we started also to use ASM and had multiple issues. Some were fixed. We use the supply order almost daily now and it saves us a lot time. In general you sould report all bugs you find on github. These days bugs are fixed in quite a short time compared to two years ago. But if the devs, don't know the bug, they can never fix something like ASM...
  9. 1 point
    Thanks. I never looked at it that way. 🙂 My original question was about finding an easy way to integrate Klaviyo (I'm not a fan of MailChimp). I'm a shop owner migrating from Shopify and had been using Klaviyo for my marketing emails. I was advised to check out PrestaShop add-ons (outside this post) for any similar services and found that Carts Guru matched up nicely. So, I have successfully integrated it on my TB store and will be using it for my abandoned cart and other marketing emails going forward. So those of you who might be interested in a MailChimp alternative and don't need landing pages can check out Carts Guru. They even have a freemium plan (which was a major plus for me).
  10. 1 point
    I can only speak for myself but here what has been my experience: When I was using Prestashop, I had tons of issues. Lots of things and modules were not working right and I spent a lot of time trying to fix things. When I decided to switch to TB, the migration was very difficult - I had more help in a week than in years with Prestashop, not a diss, just stating a fact (for which I am tremendously grateful). Like I stated, the migration was not easy by any stretch, partly because of my lack of knowledge but also partly because there was a lot of bugs. If some modules stopped working, I bit the bullet and found alternatives that worked. I used to need over 250 modules to get my shop to do what I wanted it to do under prestashop. I am down to around 140 in TB! Things are faster in TB and things that did not work well before now do. Prestashop acknowledges themselves in their boards that some of the issues I encountered were due to bugs that were never fixed. I use a super old theme and while I do have to do workarounds to get it to install properly, it is not a major issue. It works as expected otherwise. Most prestashop code works and when it doesn't, it is usually either due to bugs, compatibility issues between modules or, more often than not, server issues (some apache module was not activated or limited, or some php extension was missing). If it does not work, I have always managed to find alternatives or code them myself (with my little knowledge) and things work better than ever. I use to have nightmares and fear overrides - I have almost none now but they do what they are supposed to do. Never any issues anymore with them. I think the logic of getting rid of the bugs and get things running smoothly from the get go is sound. If the base works, then it is much more suitable to build on than trying to patch things along as we go. The lack of some functionalities might be frustrating but I find that 90% of modules work without issues and the rest can be tweaked to work. I for one am grateful and I do not take the view that the software needs to bend to everyone's wills and needs - it needs to be solid, stable and working properly and it is up to us to build on it and adapt if need be. If the platform is strong and solid, eventually developers will flock to it. That is my two cents.
  11. 1 point
    Your problem may be caused by Template Compilation setting in Performance. When you reopen your translations page you see an old copy with the old strings, when you click save they are written down together with your new changes. You should keep this at "Recompile if changed" setting to avoid this issue. The "Recompile always" will give large performance penalty and thus is not for 'production' and only for editing and fixing period. Hope this makes sense!
  12. 1 point
    That is exactly what makes you PCI compliant. And let me tell you, there's nothing wrong with leaving your site. In fact, it might help your sales. When some website ask for card details directly, I become very nervous. And unless the website belongs to a well-known company, I leave without completing the purchase. I'm just too scared to send my card details to anyone
  13. 1 point
    Any merchant that wants to process, store or transmit credit card data is required to be PCI compliant. The solution is simple - don't do that. You can choose a payment provider which complies with the PCI, and which can process, store or transmit card data, so you can avoid the whole struggle with PCI. This means that the payment company you work with processes the payments itself, so your website doesn't touch customer's cards details. They take all the PCI burden themselves. Now, if some payment provider have requirements on stores they integrate with is a completely different topic. It's not PCI, it's a vendor-specific requirement. Braintree, of course, can have any criteria for their partners. But that doesn't mean you are in breach of PCI.
  14. 1 point
    I saw that Prestashop is planning for 1.7.7 to "upgrading all the outdated jQuery versions to the latest version in all stacks without introducing breaking changes, thanks to jQuery migrate". Could that be an idea for Thirty Bees too?
  15. 1 point
    Very likely something is going wrong in one of the many product related database tables. I recently had a problem where groups where not allocated. In your case something similar might happen. The only way to find out is by having a very good look at your database. If you pm me credential I could do that for you.
  16. 1 point
    Ik ben bang dat ik het daar niet mee eens ben, want dat is niet waar. Met een paar kleine aanpassingen kon Transformer worden aangepast naar dertig bijen 1.0.8. Voor 1.1.0, althans voor de ontwikkelaarsversie, zijn geen verdere wijzigingen nodig. Het enige probleem met 1.1.0 is dat de modules één keer handmatig moeten worden geactiveerd of gereset om de frontend te laten werken.
  17. 1 point
    Is this a new installation because there also seems to be stuff on jointystems.org and jointsystems.org/shop Did this used to work and suddenly stop? Or has it never worked? If it has never worked how did you get the products inserted in the first place? If it used to work can you back track and consider what you have changed since it last worked? Looking at the site there are a lot more issues than just no products in the back office
  18. 1 point
    Have you enabled debug mode to see if there is a error
  19. 1 point
    Patching core files is not the best idea. While this indeed works, it can bring other problems down the road: you can't update your store without loosing this modification (no more coreupdater for you) if you decide to switch to different theme in the future, this will cause you troubles, as other themes actually expect jquery.jqzoom.js plugin to contain original content I would suggest you to do this instead go to your modules find Community Theme Configuration module reset it if it's disabled, enable it
  20. 1 point
    The problem is that there is some module with long controller name. Controller name is used to compose page key in form: module-<module_name>-<controller_name> for example module-paypal-plussubmit Thirtybees has limit 64 characters for these meta page entries. If (( module name lenth + controller name length + 8 ) > 64) then this error is thrown, because the resulting page key can't fit database column. This limit is obviously too small, we should increase it for the next version of tb. I've created github issue to increase this limit. Meanwhile, you can do this to fix the situation: Edit file classes/Meta.php and change size of the page property to 128: 'page' => ['type' => self::TYPE_STRING, 'validate' => 'isFileName', 'required' => true, 'size' => 64], to 'page' => ['type' => self::TYPE_STRING, 'validate' => 'isFileName', 'required' => true, 'size' => 128], You will also have to connect to your phpadmin and modify table schema (you might need to change table name tb_meta according to your database prefix): ALTER TABLE `tb_meta` MODIFY `page` varchar(128) NOT NULL;
  21. 1 point
    you need to go there, and turn on (green check) the left column on Index
  22. 1 point
    blockcategories is installed by default i think, so you just have to show left blocks on the index page? Goto BO>Preferences>Themes>Advanced Settings and change were you want the left block displayed. Then using BO>Modules & Services>Postions and change the position of blockcategories in displayLeftColumn edit the .css files directly, or edit the .sass files and re-compile the theme. There is a module coming up that will let you do the things you would like, but it's not ready for primetime yet.
  23. 1 point
    "Blutige Liebe". That's how it got translated to German 🙂
  24. 0 points
    Yeah, you can read @lesley earlier answer in this thread. Don't think there have been any changes since that post. We did some investigation to turn off all ASM and let another cloudsoftware take care of everything. We did try some out but ended up buying Prestashop ERP module from Boostmyshop. We then put some money in and let them develop the most critical features for us (which is also available for everyone else in latest versions). We also tried to get some new features developed recently but the price was a little bit too high (about 2000 EUR) to take all by ourselves. So it's the best option we have so far but we are stuck with a module which doesn't seem to get updated that much and also to expensive to develop further on our own.
×
×
  • Create New...