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 on 03/10/2019 in all areas

  1. 1 point
    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:
  2. 1 point
    Bueno, primero agradezco a los amigos del foro en inglés por contribuir con la solución. Mi caso, es que tengo una instalación de TB en español y al utilizar el formulario de contáctenos, este no funcionaba, entonces la solución: *Se asume que está en español por defecto, ahora instala el idioma inglés en TB... Ir a la carpeta /mails/ copiar la carpeta Ir a /themes/mytheme/ y pegar ahí la carpeta mails Ahora, de la carpeta mails/mytheme/en/ copiar los archivos: index.php Lang.php Y otros archivos que veas que no tiene la carpeta mails/mytheme/es/ Verificar que todo esté bien en > Traducciones > Plantillas email Listo!
  3. 1 point
    I understand, it should work. But it does not without the tradename. Remember by initial post - it affected the spanish VAT number (ES) Try these http://ec.europa.eu/taxation_customs/vies/vatResponse.html?locale=EN&memberStateCode=ES&number=B63622740&traderName= http://ec.europa.eu/taxation_customs/vies/vatResponse.html?locale=EN&memberStateCode=ES&number=B63622740
  4. 1 point
    I have not tested all variants default theme - block top menu ..... add the following code in the backoffice custom code css #block_top_menu ul li ul {display:none!important;} #block_top_menu ul li ul {display:none!important;} alternatively you can add it in the module in the file themes / community-theme-default / css / modules / blocktopmenu / css / blocktopmenu.css clear shop and browser cache and you can see only first menu - without subcategories
  5. 1 point
    i use this module https://buy-addons.com/store/prestashop/module/bamenu-prestashop-responsive-menu.html its not free, but good for some changes and it works with tb for me