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.

Traumflug

Administrators
  • Content Count

    1,319
  • Joined

  • Last visited

  • Days Won

    35

Everything posted by Traumflug

  1. Them saying this can well mean "we didn't even try". Quite a number of PS developers apparently fear new customers using thirty bees. For hardly imaginable reasons, because thirty bees is as compatible as another software can be, sometimes even more compatible than PS its self.
  2. Do you need module "cheque"? If not, uninstall and delete it. Uninstalling and deleting unused modules is generally a good idea. This brings a small, but existing performance advantage over just disabling it.
  3. I think that's called updating and yes, there is a module, of course. It's called "Core Updater" and available in the list of modules in your back office.
  4. Traumflug

    Bad Bot Alert!

    We have no magic crystal ball to see which module you mean and how these messages differ from expected messages.
  5. It is already fixed. Thanks, @datakick.
  6. I'd be keen to learn what "failed to load properly" exactly means. We have no magic crystal ball here where we can see what you did, on which page, where you clicked, how the screen looked, which messages appeared, and so on.
  7. Traumflug

    Price tax exc

    Found it: it's a setting in back office -> Localization -> Countries -> (edit country). Which means, one can enable/disable this label for each country individually.
  8. Traumflug

    Price tax exc

    I wonder why you see this at all. A default installation doesn't show this label: https://front.thirtybees.com/gifts/soap
  9. Core Updater is pretty advanced software updating technology and has shown to be quite helpful since it was released. Merchants lost fear to update their shop installation as they can roll back easily. Great! This way, developing the software actually makes sense, merchants can take advantage of all the new stuff. There was always a pimple in the picture, though: provided releases had to be added manually by a thirty bees developer. As so often, stuff to be done manually easily gets forgotten. No longer: over the recent weeks, Core Updater's background machinery has learned to build releases automatically. This is especially helpful for Bleeding Edge: the minute a change gets committed to the Github repository and passes validation, it appears in all the shop back offices. Can't get forgotten, always accurate (knock on wood). Another new thing appeared: issue branches. When tackling issues reported on Github, developers often want to show partial work or provide completed work for testing. Maybe they just add debug messages to find out what's going on in a shop installation. Now they can commit this work as issue branch, merchants will find it in the Bleeding Edge channel in Core Updater listed. Merchants update to this, test, report back their opinion in the issue tracker. Easily fast enough (~6 minutes after push) to allow timely discussions on how to implement this or that the best way. Note to developers: an issue branch is a branch named with exactly 'issue-' (including the dash), followed by a number consisting of digits only. This number should match the Github issue number. Enjoy! P.S.: this is available immediately, no upgrades or whatsoever needed 🙂
  10. The original idea of payment modules was to have one module per payment method, hence restrictions per module. One module handling a plentitude of methods wasn't on the screen a few years back. Regarding your issue, it looks much like beefing up price rules a bit could accomplish that. These are well equipped with conditions already, they just don't allow raising the price ( = negative discount). Can't promise a timely solution, though, our stack of feature wishes is huge already, on top of 100+ known bugs (which are considered to be more crucial to fix). And everybody considers his particular issue as the must have, of course 🙂
  11. We're busy improving the product, this page is a bit behind. thirty bees 1.1.0 actually comes with two themes. The other one can be seen here: https://github.com/thirtybees/thirtybees Back office to the left, front office (what your visitors see) to the right.
  12. Could you elaborate a bit more on what exactly you try to do? There are certainly a dozen places where one can upload an image. Are you trying to upload products by importing a CSV with image links inside? Which error messages do you get? For debugging it's a good idea to try with a CSV file with just 2 or 3 lines inside. Once 2 lines work, 2000 lines are no problem.
  13. Core Updater can certainly help here. Doing an "update" to the current version should restore all core files. Module files can get wiped and restored from the distribution package. Works for all modules Those few storing settings or images or whatever inside their module folder loose these settings. Settings in the database will be kept when replacing files, only.
  14. Sounds great! I reached out for them as well.
  15. The only way to get rid of this language thing is to install only one language.
  16. This is fixed now. Translations build tools have theme names hardcoded (what a shame). After adding Niara there, language packs now contain translations for this theme as well. To get this, update translations in your back office. No need for a re-installation, core files are unchanged.
  17. Unless one sets Core Updater to ignore community themes, doing an update should install all the files for the new theme. Then one can switch to it in back office -> Preferences -> Themes.
  18. Nope, sorry for that. TBH, over the last few weeks I kind of put my football gear on and hacked away without looking left or right, just for getting the thing into a releasable shape. There are a few more missing bits, e.g. installing in German gives a mostly English front office. With the release done, we can catch up on these things now, one by one.
  19. It's running on (unsupported) Windows and missing a file, so it's likely something with forward (/) vs. backward (\) slashes. According to what I read here in the forum, settings in back office should always use forward slashes, even on Windows.
  20. Perhaps you were waiting just as long as me, now it's done: thirty bees v1.1.0 (ZIP package) Packed with hundreds of bug fixes, awesome new default theme, two new modules. Release notes: Core Updater is now the tool to update thirty bees core. A lot faster, a substantially more reliable update strategy. It can update all versions beginning with thirty bees 1.0.1. And it can downgrade / roll back just as easily in case a new release doesn't work for your shop. Module tbupdater should be kept installed, it's needed for updating modules for the time being. Big refactoring of error reporting and exception handling by @getdatakick. A new exception page and more important for merchants: reports no longer go into the rendered shop page, but get reported in the JavaScript console. PHP errors messing up shop pages are a thing of the past. Another big audit of price rounding. Prices in the cart get now rounded properly according to the configured rounding strategy (by item / by line / by total). And invoices, credit slips, all now do as well. This audit also brought a lot of detail improvements in displayed prices. For details, see https://thirtybees.com/blog/prices-done-right/. In multishop environments, one no longer sees duplicate entries for currencies. Editing translations no longer requires to raise the max_vars PHP setting. Thanks to @ziyaindia. When checking for module updates, not only the module name, but also the module author has to match. This should solve a class of issues with thirty party modules named like official modules. It also means that one can exclude a (edited) module from updates by simply changing the module author, e.g. from $this->author = 'thirty bees' to $this->author = 'thirty bees tweaked'. Coupons/vouchers with taxes get now taken into account as well, thanks to @Zengraph. With multishop, lists of customer groups now list only groups available in the currently selected shop context, thanks to @chitmann. Also thank you to Emanuel Schiendorfer, David Gasperoni, Mark, Yaniv Mirel and Geo for their contributions. Much appreciated! There is a new section in the statistics module: Stats by Groups. Written and contributed by @Zengraph. Considerable chunks of theme installation were re-written. It should work now simpler and no longer mess with back office modules. This added support for different image sizes in distinct themes. Developers would call this a per-theme namespace for image types. Theme configuration XMLs in config/xml/themes/ disappeared. As they never got edited, they were always identical to config.xml in the theme folder. This also removed config/xml/themes/default.xml, which was used for community-theme-default, so no more surprises when installing a shop and re-installing the default theme. Initial theme settings in the installer were aligned with those of the actual default theme. Before, (re-)installing the default theme later had quite distinct results from what one had right after installation. Theme metas (where one turns left and right columns on and off on particular pages) now allow to configure not only pages known by the theme, but all pages available. CSV import now supports custom date formats in CSV data. This should allow e.g. U.S. merchants to import CSV data from a European manufacturer. Thanks to @ksimunovic! A new, awesome looking default theme, Niara. Previous theme is still there. Now one can switch back and forth between both themes coming with thirty bees. Support for the "back" step with third party themes is forthcoming, one can still install them, of course. Module beesblog is now a default module. Two new modules, thememanager and tbhtmlblock. Already in use by theme Niara, they get disabled when installing theme community-theme-default. Modules & Themes Catalog can now actually list modules and themes. Notes to developers: Price rounding audit contained the following steps: Get the cart into rounding properly. When creating an order, take these rounded prices from the cart unchanged. This ensures all downstream calculations use these rounded values rather than the current product price. This also allowed to remove duplicated rounding in classes like HTMLTemplateInvoice or HTMLTemplateOrderSlip. As a metaphor, consider rounding to be like a discount: price in the order is what the shop customer saw, not what the merchant started with. Reviewed all classes dealing with prices to always round to database precision. As if PHP couldn't do better. For strategies, see Dealing with Prices at Traumflug's. Replaced a whole lot of (hopefully all) hardcoded rounding precision values with constant _TB_PRICE_DATABASE_PRECISION_ or Configuration::get('PS_PRICE_DISPLAY_PRECISION') as appropriate. Controllers rendering option fields ($this->fields_options[]) containing prices should use field type 'price', validation 'isPrice' and, new, a cast 'priceval'. The latter converts to a float, then rounds to database precision. AdminController was changed to apply the cast for option fields ($this->fields_options[]) before validation, not after. This allows to implement a cast which shapes the value (like priceval() does). There is a new field type for a class' storage field, type TYPE_PRICE. It's a float like TYPE_FLOAT, but also rounds the value to database precision, to get precisely predictable price and tax calculations. Started to remove outdated code. Retrocompatibility code for PS 1.4 and before or PHP 5.5 and before. Removed AdminRangePriceController and AdminRangeWeightController. Introduced in 2011, they were never available in back office. Classes RangePrice and RangeWeight are kept, of course. Themes now support only one variation. Not sure whether multiple variations every worked before, code had quite a number of discrepancies. Attempting to install a theme with multiple variations now reports an error. To get the path of the config file of a theme before and after 1.1.0, use Theme::getConfigFilePath(). Image type names are now enforced to contain the theme name. Recommended standard is to let the system do this, it prefixes the theme name. For getting links to product images, use Link->getImageLink(), for getting product image sizes, use Smarty getWidthSize and getHeightSize, see e.g. in _productlist-item.tpl in both thirty bees themes. For getting just the appropriate type, use ImageType::getFormatedName(). Other variations are allowed as well, see ImageType::getFormatedName(). And yes, fallbacks for hardcoded image types were implemented. They come with a small performance penalty, though. To see how to fix a theme with hardcoded image types, see commits like https://github.com/thirtybees/niara/commit/1047053d4829ecaf7e5bbdbad891bba286863b07 or https://github.com/thirtybees/niara/commit/7f682df10940170593bbe6d21ea99dd74ebe77ae. There are a whole lot of new hooks, see New Hooks in 1.1.x in our forum. And yes, we're aware this has taken waaay to long. thirty bees should release more often. This release also appears in Core Updater in you back office.
  21. Turn on debug mode in back office -> Advanced Parameters -> Performance and try again. It should be much more verbose about what's going wrong, then.
  22. Pretty much all of them work, incompatibilities with PS modules and themes are considered to be a bug. Exceptions are modules with functionality implemented natively in thirty bees, like pretty URL or updater modules. They'd be pointless even if they'd work. While thirty bees enhances a lot of details, it also maintains backwards compatibility. And yes, welcome to thirty bees. For a definite answer to your question, just install and try. There's also module psonesixmigrator, which migrates PS shops to thirty bees with all its settings, categories and products: https://thirtybees.com/migrate-from-prestashop/ https://github.com/thirtybees/psonesixmigrator/releases/latest
  23. Let's not forget this: https://github.com/thirtybees/thirtybees/issues/998
  24. This extra page on theme installation was removed recently, that's true. But not with 1.0.8, it's 1.1.x and later only. Modules don't get uninstalled, they get disabled. Which means, they keep their settings. They can get re-enabled in Modules and Services any time. Simple point of this intermediate page removal is, themes should appear as the theme developer designed them, not appear depending on what modules were installed or not installed before. If a merchant has a different idea about how the theme should look, s/he can change this with the theme already installed. Another thing changed with 1.1.x: many modules are no longer considered to be theme related, like updater modules, like dashboard modules, like statistics and payment modules. These are left untouched on theme changes. It was a bit odd to see statistics modules in back office disabled or newly installed just because the front office theme changed.
  25. That's probably a Yes. Changing _TB_VERSION_ in config/settings.inc.php should be sufficient. It can get restored after the installation.
×
×
  • Create New...