Traumflug

Module Override check cannot be upgraded: Error while extracting the latest version. Found a typo in the file on api.thirtybees.com listing versions for this module. It should work now.

Because you turned validation off, like in the picture in the other thread. Then it always works for thirty bees. Anyways, I've filed an enhancement request: https://github.com/thirtybees/thirtybees/issues/605 And if you're in search for some entertainment for code writers, here's the Wikipedia elaboration about the matter: https://en.wikipedia.org/wiki/PostcodesintheUnitedKingdom#Formatting (it's complicated).

Thanks for the examples, @colorful-ant. Smells a bit like post codes of varying lengths aren't really supported for validation. Keeping the field empty disables validation, which always works, of course.

Post codes do not work in TB for UK . It'd be helpful if you could give a (or a few) example post codes not working.

Such a list looks much like forgotten debug code. If you can, search through all the PHP files for var_dump, var_export and ddd. Production code shouldn't have such stuff.

To get a module uninstalled like in "all files removed" one has to delete the module. Then installing it again also downloads the package again.

Been waiting a long time for some of the enhancements to come to fruition, especially a one page checkout that isn’t outdated like the current one and a modern theme. If you expect just (free) eye candy, theme developers are the right address for such wishes. The whole point of thirty bees is not to be a PrestaShop clone, but to shift emphasis. Emphasis towards performance, ease of use and the most crucial topic for merchants: reliability.

Filed an issue report for this, which also describes the workaround: https://github.com/thirtybees/thirtybees/issues/604

Filed an issue report for this, which also describes the workaround: https://github.com/thirtybees/thirtybees/issues/604

While you're talking to them you can also show them how submenus expand to outside the screen: They might be interested in fixing this. Window width ~1000 pixels.

One can't entirely delete these rules. Every page needs an URL, after all. {rewrite} is the minimum, as indicated by the required-star in the description below each field. Remains the question how you managed to get these fields empty. They should be filled properly with a standard installation.

I’m working on Prestashop 1.7.2.1 Say hello to thirty bees! Here we actually solve misalignments and bugs.

These three messages are warnings, only. Well known, but not much we can do about, because some are dependencies of other packages and others (phpspreadsheet) aren't compatible with PHP 5.5. Regarding missing files. Which way of upload did you choose? Cloning the Git repository? When unpacking the distribution ZIP file, there should be no need to run composer.

Too bad, Ubuntu no longer comes with a Flash player. So I added {id} to some of the rules. They got stored and the product URL indeed changes. That's about what I'd expect. Did you notice that these rules are per-language? If you change the English rule, the Spanish one will stay on its previous value. One has to change all of them.

"Versuch macht kluch" A German phrase for "try it, and you'll find out" thirty bees puts a lot of emphasis on keeping compatibility with PS 1.6 while improving reliability and performance. Chances to get positive results are excellent.

Unless I'm mistaken, using the same route templates in thirty bees leads to the same URLs. One can still use an {id} in there, it's just no longer the default and no longer necessary.

Yes, this http:// is hardcoded in a whole lot of places. ... and https:// as well. :-) To allow both, or to prefer HTTPS, see back office -> Preferences -> General, right the first two switches.

Perhaps they can get fully automated one day, but that's certainly not trivial. ... and now I'll return to writing the Git Updater, which will allow upgrading to the tip of a development branch.

Ha ha! A "minor" automated system! :-) More seriously, while it sounds pretty easy to run build.sh in the development repo, which indeed gives a release ZIP, there's plenty of correlated stuff: Reviewing all the modules for changes since the last release. Create module releases as needed. Generating translations and uploading them to Crowdin. Packaging translations on Crowdin. Creating Diffs for the updater. ... and so on. Making a release covers some 30 (manual) steps and is about a day of work. And yes, you're right, 1.0.6 is about a month old, so time to think about 1.0.7.

Here's a patch to fix the issue I see, fresh from the monday morning breakfast table: https://github.com/thirtybees/thirtybees/commit/f9372264805c8a7abc1b43fffd02849d7c231853 Issue is/was, that two files in this translations package use $_MODULES = [] rather than the older $_MODULES = array(). Now I'd be interested if it works for you as well, of course.

I tried as well and get this, right after the import: Does this match your experience?

Duplicate of https://forum.thirtybees.com/topic/2017/unable-to-import-a-language-pack-at-tb-1-0-6

@musicmaster about 16 hours ago I am a bit puzzled about those claims about many incompatibilities. It's fairly simple: 99% (100%?) of these messages originate in Smarty code. thirty bees currently uses Smarty 3.1.19, a ~~two~~ four years old version. Upgrading Smarty was under consideration, of course: https://forum.thirtybees.com/topic/1950/call-for-votes-for-or-against-upgrading-smarty Result of this consideration is that Smarty will be kept at its current version up to end of the year. Because any upgrade is seen as a risk regarding compatibility with PrestaShop themes and modules. We want merchants migrating from there to feel as comfortable as possible. In January I'll happily upgrade Smarty, because I see these messages as well, day in, day out. If you want to do this now, and have a developer installation, proceed like described in this post.

@the-rampage-rado said: Can you tell me how I can troubleshoot this one on my own? @Traumflug said: Like disabling these other modules and testing again.

Testing Captchas should, like any security measure, be theme independent. Malicious users can change their theme (HTML, CSS, JS) arbitrarily, after all. Nevertheless I asked, because the theme might just ignore the error message, giving the impression of an email being sent without it actually happening. As Captchas work in a default installation, but not in your particular installation, other modules are the prime candidate for finding the issue. Like disabling these other modules and testing again.