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.


Popular Content

Showing content with the highest reputation since 01/09/2019 in Posts

  1. 11 points
    Hi everyone, I needed a way to log into my frontend as one of customers. Because I couldn't find any module that would work correctly on thirtybees, I've build my own. I have decided to release it as an open source / free module. So, if anyone need this functionality, you can download it on my store. url: https://store.getdatakick.com/en/modules/login-as-customer github: https://github.com/getdatakick/loginas
  2. 9 points
    Unfortunately there is no technical solution for this. Thirtybees just can't force any third party to support it. It's also not possible to build some sort of facade on top of the tb codebase in order to make ps17 modules work with it. I understand your fears, I really do. After all, it's your livelihood we are talking about. You need to decide what platform is best for you and your business, now and in the future. Let me just remind you that going with prestashop is risky as well. What will happen when they start working on ps18, dropping the compatibility once again? Maybe your theme will stop working, modules you bought will be useless, all the customization work lost. All because prestashop company doesn't care about compatibility, stability, or merchants themselves. You will be left high and dry. Trust me, they did this many times already, and they will do it again. Thirtybees, on the other hand, was based on a pledge of stability and compatibility. But of course, because the user base is much smaller, third parties don't have such incentive to support it. But I believe there is still great amount of ps16 merchants that appreciate the stability this platform offers and will migrate here. And with our user base increasing, there's a hope third parties will be more inclined to support it. Especially since they already have ps16 modules they invested great effort into. And thirtybees is a way for them to continue monetizing them. Now, it's up to you to decide what way is better for you.
  3. 7 points
    Hey guys, i created this theme based on community theme with clean design, some additional modules and second image on hover. You can see demo here: http://demo.worldtriangle.com/niara/ and download it here: https://gum.co/niara100/ Update 05.03.2019 Fixed missing option of some text translation in WtBlockBestsellers module Fixed invisible checkbox for terms and conditions if AEUC module is enabled Fixed customer registration from countries without states
  4. 6 points
    Well, I think it's time to talk a bit about this next release. Last November, I planned to release it on New Year's Eve. As everybody can see, this didn't work out. How could such an utter mis-planning happen? Well, there was this issue with broken price rounding. A Github issue and the reporter even sent me a patch for correcting the misbehavior. Should be a matter of a day for applying and testing this patch, right? Things turned out to be not that simple. Each look at the code came up with more small issues regarding price rounding, the TODO list grew and grew ... and it took over two month to settle the whole topic. Then thirty bees had much more reliable price rounding, but it was also late February. A similar thing happened a couple of weeks ago. thirty bees 1.1.0 will come with a much nicer, cleaner theme. Switching the default theme on installation should be a matter of flipping a switch, right? Well, as it turned out, not really. Initial theme installation was found to be entirely distinct from a theme installation done in back office. Huge amounts of handcrafted SQL and XML files instead of a procedure installing the actual theme. Which means, since 4 weeks I'm working on separating theme installation from AdminThemesController, into class Theme, to make it available to the installer as well, and to get rid of all the handcrafted SQL and XML, which is hard to adjust to another theme. Also fixing bugs found in this area, of course. I'm not there yet, probably it'll take another two or three weeks. And then I can flip the switch. What does this mean for merchants? Good thing is, they're not lost. During all the time described above, branch 1.0.x wasn't abandoned, but received many many bug fixes, making thirty bees more stable than ever before. The only thing missing thing there is a formal release. Making such a release would throw back the 1.1.0 release by another week or so, so it's not on the TODO list. We have Core Updater, after all, and @datakick regularly runs some voodoo to update its master repository, which allows to update to latest 1.0.x. That's what a merchant should do. It's named "Bleeding edge", actually it's currently more stable than "Stable". Want a return to monthly releases? Yes, me too!
  5. 6 points
    Announcing this here, because this module doesn't appear in your back office automatically and bugs prohibiting migration from an entire group of PrestaShop versions were fixed. Fixed one general bug which could cause downloads without timeout, leading to unhandled script abortion. Fixed two bugs prohibiting migrations from PrestaShop (and probably similar versions). Make it pass validatemodule.sh as far as expected. As always, find the download on the release page: https://github.com/thirtybees/psonesixmigrator/releases/tag/2.0.1
  6. 5 points
    When visitors first come to your store, thirtybees tries to detect country and currency. It uses browser's language to do so, but this method is not very precise. Alternatively, you can enable build-in geoip functionality and use maxmind geoip database to detect country based on IP address. Unfortunately, thirtybees uses legacy (no longer supported) version of this database, so it has become outdated. If you are using Cloudflare in front of your server (as I do), you might know that cloudflare do GeoIP translation and sends this information to your thirtybees server in custom HTTP header. I don't know what database they are using, but I would it's some very expensive and up to date solution. It would be insane not to utilize this information. So I've developed a very simple module that uses this http header to set up customer's country and currency. It does so only on first pageview, when cookie does not exists yet If you are using cloudflare as well, you can download and use this module for free: Cloudflare GeoIP
  7. 5 points
    Migrated to TB about 1 month ago and today i finaly finished modding the community-theme-default. - Shrinked 5step checkout into aka 3 step. - Optimized it for mobile - added v3 fancybox with swipe function - added side bars with buttons on nav-bar - used block-categories-footer for mobile sidebar category menu (didn't manage to integrate stock into both views without having issues) - added colapsable footer shop.alza-racing.com
  8. 5 points
    It's sad that Mollie does not support thirtybees natively. But I'm also pretty sure they do not intentionally block thirtybees. In fact, there is nothing in the api request that would provide information about used platform. Mollie is an api-based solution, and anybody can integrate with them. It doesn't matter if it's open-source, or custom made proprietary solution. They don't really care. This whole flame is based on a fact that some part of the official mollie module does not work on thirtybees. This can, of course, happen. You all know that there are some modules that need some modification, attention, and love. I guess the problem here is in webhook implementation. It either fails with some 500 error page, or maybe short-circuit the processing due to some condition. Because webhooks are triggered by Mollie automated service, nobody notices these errors. We observe them only indirectly by the fact that the order status does not change automatically. But that does not mean that Mollie is blocking thirtybees, now does it? Let's calm down and work together to troubleshoot this problem.
  9. 5 points
    Hi everyone, I've released a new premium version of revws module. Upgrade 2.0.4 brings one of the feature everyone asked me about - Store Reviews. You can check this new functionality on my demo account - front office / back office. If you don't need this feature, free version is still there and fully supported.
  10. 5 points
    I have just pushed live a release for the Paypal module that fixes the "An error occurred" message. I also released an updated version of the Bees Blog, with several new SEO focused features, bug fixes, and some new hooks for the module. Both releases should be live in your back offices.
  11. 5 points
    Don't be surprised if it looks like nothing happens. With the comparison done, updates are quite speedy: That's 0.2+0.6+0.1+0.1 = 1.0 seconds for the whole download and update process. Shop downtime is even less, it's just the time between Created update script and Update script was executed. Apparently less than 0.1 seconds.
  12. 4 points
    The flawed update mechanism Perhaps you remember the 1.0.8 update a couple of weeks ago. While it certainly solved bugs and misalignments for many, it also resulted in quite a number of reports about messed up shops after the update. That's not tolerable, of course. Thinking about this problem I compared to what we developers do to switch between versions, and why we pretty much never mess up a shop installation by doing so, despite switching back and forth all the time. Developers do a git checkout 1.0.7 to switch to version 1.0.7, git checkout 1.0.5 to switch to version 1.0.5, git checkout 1.0.x to switch to the latest development, and so on. And there's the fundamental distinction: doing such a checkout doesn't apply a patchset or a set of changed files, like the current updater module does. When checking out a version, Git compares files currently on disk with kind of a master set of files (stored in the .git directory), then changes files on disk to make them match this master set. The current update module, which is a refined version of Prestashops 1-click updater, has a fundamental flaw: it doesn't check whether files on disk are right, but blindly applies a set of changed files. Who creates this set of changed files? Right: thirty bees developers, which have never seen your shop installation. This set of changed files gets created not on knowledge, but on assumptions. The assumption that your shop installation matches a clean shop installation. Which is often not true, as we unfortunately experience over and over again. Meet GitUpdater Having the fundamental flaw detected, a new updater module started to evolve. Prepared sets of file changes are gone. Instead, the module compares the shop installation to a clean master installation, which gets served by api.thirtybees.com. This always works, and after an update, a shop will always be in a clean, sane state. A recipe for reliability. Advantages This works from any release to any release. Select the wanted version, click Compare and see which files changed since then. Which means, one can downgrade or rollback just a easily as update. Another use case is to compare the current installation to the master installation. Updating from e.g. 1.0.8 to 1.0.8 is perfectly possible, to restore a broken shop. Before too long, this will also support updating to development branches. E.g. to test bug fixes provided on Github. Or even single commits. Manual changes get detected. During comparison, the module detects files which don't match the original version, so the merchant can deal with his manual edits. Smooth operations. All operations taking place got split into small chunks, so one can virtually never run into maximum processing time limits. The preview Here it is: gitupdater-2019-01-05.zip Install it by unpacking in the modules folder or using Add a new module (top right corner) in back office -> Modules & Services -> Modules & Services. Having the module installed, a new menu item, Updater, appears in menu Preferences. That's where this module gets controlled. Yet To Do Actual updates. Currently the module does comparisons only, not actually change files. Which is why playing with this module preview is safe. File filtering. Some files should get ignored. For example, an update shouldn't reinstall the install/ folder despite this folder being present in a clean installation. It also shouldn't remove product images or translations, despite them being not present in releases. User interface. Currently, this module shows a list of all changed/created/removed files. This can be a huge list with up to 10,000 lines. Ideas to display this list in a less scary way are welcome. And for those not installing the module immediately, here's a screenshot:
  13. 4 points
    Together with the help of @haylau a number of nice improvements were introduced: Now using the recommended SOAP interface, rather than web pages intended for consumption by humans. Can distinguish between a negative report and a web service outage now. On web service outages, all VAT numbers get accepted, to not disrupt a purchase. These events get logged to allow manual verification by the merchant later. Improved settings descriptions. Release notes and manual download: https://github.com/thirtybees/vatnumber/releases/tag/2.3.0 Also available immediately in your back office, of course.
  14. 4 points
    Another free version 1.0.23 released Enhancements Issue 86 - custom placement for review average - you can now position stars/ratings widget anywhere on your product page. For example prominently below product title Issue 97 - added shortcuts from settings page to reviews, import, criteria pages Issue 100 - added configuration option for number of reviews to be displayed on all-reviews / my-reviews page Issue 48 - you can now edit review date from back office Issue 47 - review lists can now be filtered by category and brand. Bugfixes Issue 90 - fix pagination problem that occured on some versions of MariaDB without proper support for SQL_CALC_FOUND_ROWS Issue 96 - fixed overflow problems with long review content Issue 20 - read review link now works in quick view Issue 99 - don't filter reviews on my-reviews page by selected language Tip and tricks Try adding this short snippet somewhere into your smarty template. It will display product reviews associated with category 4 {hook h='displayRevwsReviewList' category=4 }
  15. 4 points
    I believe you can expect next version very soon. Maybe even in two weeks time. And after the new @Traumflug's core updater is released, you will be able to deploy latest changes almost immediately
  16. 4 points
    Not really. PS 1.7 did a few things right and if thirty bees needs something similar, it'll implement this in a similar fashion. No need to alienate module developers more than necessary. But that's about it. thirty bees simply has distinct goals. Like improving reliability and ease of use. Look at the upcoming GitUpdater, Lesley has something in the works, too.
  17. 4 points
    Alright, time for another preview. Advances since the last preview: Updates now actually work! So far tested with a clean installation, one can switch between v1.0.7 and v1.0.8 back and forth as often as one desires. Applies the same database upgrades as upgrading to v1.0.8 with the old updater did. Which means, all the essential stuff is implemented. Still missing: Some nice exit. Currently, one is kind of stuck after an update and has to select something in the menu to move on (and see the new version in the upper left corner). Actual removal of selected obsolete files. So far, these checkboxes are just decoration. Machinery to update the underlying clean master installation automatically. To allow merchants to update their shop a few minutes after a Git commit was pushed to the Gitub repository. To demonstrate the modules' capabilities, I've uploaded current branch 1.0.x manually. Happy updating! gitupdater-2018-01-21.zip
  18. 3 points
    Here we go: https://github.com/thirtybees/thirtybees/commit/1818e2aca9b90dbee0553272e45956b275fda334
  19. 3 points
    @koraledrewniane Yes, it's a bug, sorry for that. Please open file themes\niara\modules\wtblockbestsellers\views\templates\hook\wtblockbestsellers-home.tpl and change: {l s='most'} to {l s='most' mod='wtblockbestsellers'} That should fix it.
  20. 3 points
    You need to run your store on https
  21. 3 points
    Error reporting, as originally implemented in php language, is one of the worst design they could choose. It worked somewhat at the time they invented it, but 20 years later it just doesn't fit well into modern stack. When this error_reporting *feature* is turned on, then any error or warning will be printed into the standard output -- into the currently rendering document. Why is this bad? It breaks the document. Note that php can generate different types of responses, and this feature can break all of them html output -- error message text, which can include html special characters like </>, will be part of the response. Depending on the place in the code where the error happened, the error message can be at the very beginning of the response (before the <html> tag), anywhere inside it, or after. If it's before, then the response is not valid html page, and browsers react accordingly. If it's inside the page, than it still can break the layout, resulting in javascript not working correctly,... Also, we can never be sure that we actually see the error message on the page. It is very common that the error message is hidden somewhere (inside display:none divs, in overflow areas, etc...) json -- many ajax requests expects json response. When there is error message mixed into the response, then the javascript will not be able to parse the response, which breaks the basic interaction functionality. css - if php generates css, than any error message inside it will break design images - yes, php can mix these error messages into binary streams These problems makes debug mode very hard to work with. Because responses generated in debug mode are different than the response generated in production mode. That's just stupid. The new thirtybeees error reporting feature suppress error outputting, but collects the message anyway. When the page is rendered, then these errors are (in debug mode), emitted as javascript objects into the page, and displayed into javascript console. So you don't need to download error log each time you make a change, you can simply open javascript console in your browser. Also, there will be modules (I personally work on one) that will display these collected errors in more user friendly way -- for example in some debug bar. Note that this feature has nothing to do with php72 compatibility, or with smarty. It's a generic problem that was part of the prestashop/thirtybees from the beginning. Thirtybees core is fully compatible with php7.2, but it is NOT compatible with php7.3 and higher. When we run thirtybees on php72 in debug mode, then deprecation warnings are displayed. These warnings are harmless, they just inform developers that something will have to be changed in the future. And we know about it, there are definitely plans to make thirtybees fully php7.3 compatible. But because of the error_reporting described above, these warnings breaks about everything in your store. With the error reporting redesign, your store will work as expected, even in debug mode on php72. While php73 compatibility is definitely a high priority task, it's not the most pressing at the moment. There's no need to rush into any decisions regarding smarty. Current version of smarty, as the rest of thirtybees, is fully php72 compatible. Any decision needs to be carefully evaluated, because y'all will have to live with that.
  22. 3 points
    Thank you very much Petr and Lesley for your vigorate words on our perspective with Thirtybees. I know that all this arrousal came without any heads-up and no one heralded this. And you are absolutely right we have to face the actual situation and perhaps we (you 🙂 ) can workout a solution. I think the Mollie support is willing to help out, too, since we are dependent on PaymentServiceProviders as they are dependent on us. I for my part am willing to pay for the extra time needed in form of developer hours. I profit from Mollie, if it is working, and would have to spend many hours to find and integrate an alternative solution (where the same could happen). I do not know wheather there is now in this forum or in our blog a place where we can utter our top wishes that we merchants are willing or capable to pay for.
  23. 3 points
    Sorry, that is not a best solution. It is just a cover-up of a bigger problem: there is something in your system that is trying to set Blowfish object inside your Cookie. There used to be a _cipherTool property inside Cookie class. This protected property used to hold cookie encryptor instance. I bet you have some Cookie override that tries to set this (now not existing) property, which in turn causes the fatal error. You can try this: revert your fix edit class Cookie.php at the very beginning, add this line: protected $_cipherTool; That should fix your problem. Anyway, this is a core compatibility issue, and it should be handled in the core.
  24. 3 points
    Glad to see this module works for others, too. Y'know, operating it as the developer, who knows every detail, is a different thing than handing it out to people just trying intuitively. Give me another day or two for getting this module ready for release. Over the recent days I tackled all the smaller details, like actually removing marked obsolete files, like backing up manually edited files, like reviewing update script execution to avoid this CORS problem, such stuff. Also a new thing is a class for requirement checks. Not much inside, yet, because requirements didn't change between 1.0.0 and 1.0.8. Still it should meet this suggestion of "adding requirements". Having it in the update module means that it's also there for older versions. Nah, instead of talking so much, here's another preview: gitupdater-2019-01-29.zip
  25. 3 points
    That statement is true every theme... because it's a problem of smarty engine, not theme itself. Thirtybees will eventually migrate to newer version of smarty that does not generate warnings / notices. But since that is very dangerous step, we are in no hurry to do that, and we want to have contingency plans in case new smarty version does not work as expected. That means some way to switch to older smarty version. In 1.0.9 error reporting was revamped, and the display_errors php settings in dev mode was disabled. That means that the theme will work just fine on php7.2 (you will still see the warnings / notices in error log, but not in the page itself).