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 all areas

  1. 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.
  2. 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.
  3. 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.
  4. 3 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/
  5. 3 points
    Hi alle, I was just searching for a method to make it possible to have collapsible in our CMS page and found this useful tutorial: https://mypresta.eu/en/art/developer/create-collapsible-accordion-prestashop.html I thought it might be helpfull if somebody need it :). Best regards, Umar, Unica e-shop
  6. 3 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:
  7. 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
  8. 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).
  9. 3 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
  10. 2 points
    I am not at all an expert on page load time. But nowdays modern browser show quite nicely, where the time is "spent" on. Often a website is slow, because of many requests. Every image (non cached) means a reqeuest to your server. This can have serious negative effects on your page load time. To deal with it, you can use "Lazy Loading" Plugins. Another way - which I like more - is to defer images. Yesterday I found the following article: https://varvy.com/pagespeed/defer-images.html IMO the artice is very easy to understand. If you want to implement it in your shop: You just need to adjust tpl files of your theme. The <script> part can be added in footer.tpl. The rest depends on what you want to achieve. As an example: https://www.spielezar.ch. The images on the footer (payment logo and facebook image) are loaded deferred. For the visitor there is no difference at all, as this images are not in the view when the page is loading. But the page just loads faster. If you have any questions about it, feel free to ask!
  11. 2 points
    I imagine everyone has noticed that we launched a new forum over night. We should have most things transferred over. One thing that did not / will not make it is personal messages. Since there was no automatic way to migrate the forums, we had to do everything by hand. Because of privacy we did not even attempt to migrate the messages. If you notice any bugs, which there are a few still, please let us know by replying to this thread.
  12. 2 points
    Add this code to the \controllers\admin\AdminImportController.php else{ unset($product->tags[$key]); } This fix can be added to next version of TB.
  13. 2 points
    That's a problem of your csv file, see attached pic, I got the same error when I tried to add an empty tag. I will soon send you a small fix to don't add empty tags to avoid having the error.
  14. 2 points
    D'oh. That's debug code and fits my local installation only. You can delete this line or wait a few days for the release. TODO list has become short: Find, report and uninstall known incompatible modules (which should solve the problem with statistics modules). Add a switch to ignore the community theme.
  15. 2 points
    After writing an article for the blog about the Git Updater tonight I really got to test it well with different versions upgrading, downgrading, and comparing files. It works really well. Honestly, I have not found any bugs yet in it and I did just about every version combination. There are a few small changes that I think would be good for the module though, nothing major. I think for the Bleeding edge, if another version other than the latest is selected, it should be removed. Also, I think we maybe should follow the naming convention of other software and call it either the nightly build or daily build. This one is going to be tougher than those. I think we also need to scan the modules for version compatibility and at least warn users. Like if we are trying to downgrade from 1.0.8 to 1.0.3 and there is a module that require 1.0.4+, there should be a warning. Maybe even an option to set the module aside. The last thing, is small, It would be good UI/UX if the message detected what is being done, like "Process downgrade" or "Process upgrade". Really, those are the only things I found and they are pretty small. One thing I would like input on from everyone. What about adding a requirements file to the main repo? That way we can compare the version system requirements against the current settings on the server. This would be useful for growing past 1.0.x.
  16. 2 points
    Vielen Dank, es hat geklappt ☺️
  17. 2 points
    @Brian the problem with missing theme configuration page was solved a week ago, it will be part of the next release. If you need it right now, you can use traumflug's new gitupdater module and migrate your 1.0.8 to bleeding edge branch. That will pull this change to your server. Then you can reinstall the theme Or you can simply apply this commit: https://github.com/thirtybees/thirtybees/commit/e6e5b9f3a5b8a59078fc9e5184e2f24d3c5a2bce
  18. 2 points
    Yeah, there will be one soon. I am familiar with the issues, that is why I have been testing a fix out to make sure it will work for the widest group of shops.
  19. 2 points
    Great, I think this has been tested well enough, I just committed it, we will release a build soon that includes it.
  20. 2 points
    That's a nice feature suggestion, I've marked it down, the current checkout page is too long, but adjusting the layout may cause visual compatibility problems with some 3rd party modules.
  21. 1 point
    Nevertheless, when you upgrade to newer version, you will loose this modification.
  22. 1 point
    6 hours ago, datakick said: Works very nice and fast. Congrats on this release! I tested it a bit, and here are my notes: 1. my locally modified files are correctly listed in Files to get changed, but are not marked as M (this worked when I updated from 1.0.8 to 1.0.x, but when not when downgrading back to 1.0.8) Uhm, it's not a release, yet 🙂 As you noticed, Bleeding Edge versions mess up the file comparison. To make functions like version_compare() work, Bleeding Edge versions set the shop version to something like 1.0.8-1.0.x, where the part before the dash is the version found in install-dev/install_version.php and the part behind the dash is the name of the Git branch. This doesn't get resolved backwards, yet. It's on the TODO list.
  23. 1 point
    Schwer zu sagen. Ich hatte noch kein solches Problem. Welche Url Struktur nutzt du? Hast du mal versucht Externe Module und Overrides zu deaktivieren? Das kannst du bequem unter "Leistung" machen. So kannst du den Fehler eventuell eingrenzen.
  24. 1 point
    Is there a way or module to make the customer double enter their email address during registration to make sure they entered the correct address. We have a lot of people mistyping their email addresses.
  25. 1 point
    I really think in the end you will find it is module based. Something likely with an ipn is connecting back and supposed to set something, but is accidentally (a bug) cancelling the order. I wonder if that module has a hard coded status for delivered, like its just setting a specific status without checking. You might check that. It would be kind of tedious, but see what status cancelled is in your shop, then search the module for that id number.