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.

Occam

Members
  • Content Count

    231
  • Joined

  • Last visited

  • Days Won

    3

Occam last won the day on September 23

Occam had the most liked content!

Community Reputation

81 Excellent

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 😊 yep ... but, sorry, I should have read the whole message. It was caused by a module for partial shipment which was still installed and working but wasn't displayed in the modules section any longer since I upgraded my test shop to Bleeding Edge. (Just another 1.1.0 bug.) The message disappeared after renamed the module's directory.
  2. Nope, This would lead to just another error message.
  3. You forget that that the column name has always been a required field in in order_state_lang, which is left joined in the sql query. public static $definition = [ 'table' => 'order_state', 'primary' => 'id_order_state', 'multilang' => true, 'fields' => [ 'invoice' => ['type' => self::TYPE_BOOL, 'validate' => 'isBool', 'dbDefault' => '0', 'dbNullable' => true], 'send_email' => ['type' => self::TYPE_BOOL, 'validate' => 'isBool', 'dbDefault' => '0'], 'module_name' => ['type' => self::TYPE_STRING, 'validate' => 'isModuleName', 'size' => 64], 'color' => ['type' => self::TYPE_STRING, 'validate' => 'isColor', 'size' => 32], 'unremovable' => ['type' => self::TYPE_BOOL, 'validate' => 'isBool', 'dbNullable' => false], 'hidden' => ['type' => self::TYPE_BOOL, 'validate' => 'isBool', 'dbDefault' => '0'], 'logable' => ['type' => self::TYPE_BOOL, 'validate' => 'isBool', 'dbType' => 'tinyint(1)', 'dbDefault' => '0'], 'delivery' => ['type' => self::TYPE_BOOL, 'validate' => 'isBool', 'dbDefault' => '0'], 'shipped' => ['type' => self::TYPE_BOOL, 'validate' => 'isBool', 'dbDefault' => '0'], 'paid' => ['type' => self::TYPE_BOOL, 'validate' => 'isBool', 'dbDefault' => '0'], 'pdf_invoice' => ['type' => self::TYPE_BOOL, 'validate' => 'isBool', 'dbDefault' => '0'], 'pdf_delivery' => ['type' => self::TYPE_BOOL, 'validate' => 'isBool', 'dbDefault' => '0'], 'deleted' => ['type' => self::TYPE_BOOL, 'validate' => 'isBool', 'dbDefault' => '0'], 'active' => ['type' => self::TYPE_BOOL, 'validate' => 'isBool', 'dbDefault' => '1'], /* Lang fields */ 'name' => ['type' => self::TYPE_STRING, 'lang' => true, 'validate' => 'isGenericName', 'required' => true, 'size' => 64], 'template' => ['type' => self::TYPE_STRING, 'lang' => true, 'validate' => 'isTplName', 'size' => 64, 'dbNullable' => false], ], This is nothing new, and like PrestaShop before tb 1.1.0 creates the database table tb_order_state during the install procedure, see /install/data/db_schema.sql: CREATE TABLE `PREFIX_order_state_lang` ( `id_order_state` INT(11) UNSIGNED NOT NULL, `id_lang` INT(11) UNSIGNED NOT NULL, `name` VARCHAR(64) NOT NULL, `template` VARCHAR(64) NOT NULL, PRIMARY KEY (`id_order_state`, `id_lang`) ) But there seems to be a bug in some fresh installations, because like shown in the previous post the order_state_lang fields are created in the database table order_state.
  4. Occam

    Broken images

    We both know this is nonsense. But my priority has always been a fast working shop, easy to handle for users. Perfect clean code as a desideratum, yes. But not on top of the agenda. For a merchant a shop system with some known bugs that may easily be circumvented is a thousand times more useful than a new designed shop system with unexpected bugs lurking everywhere. We face this with PrestaShop 1.7, and unfortunately now with thirty bees 1.1.0. And there is a difference: Prestashop is a known player in ecommerce, thirty bees wants this to be. However, that said, I got the subtext of your posts and will withdraw from thirty bees, of course. I really don't know if you're primarily interested in a functioning shop system as an alternative to Prestashop, or just in satisfying personal vanities. In any case, it seems to be a constant lonely individual fight, even if you are well skilled technically. I wish you good luck.
  5. Occam

    Broken images

    😊 Come on, don't get upset. Just stay objective and stop such polemics. I didn't attack you personally and I don't see any reason for it. I really have a lot of sympathy for this project. Otherwise I wouldn't get active here. But that doesn't mean I have to endorse all of your solutions.
  6. Occam

    Broken images

    Sounds good, really! Plausible and convincing. But after reading your explanation why it should be demanded to avoid such 'blasphemy' I took a quick look into the thirty bees marketplace, and afterwards into PrestaShop Addons. And you know what? There is currently this normative power of the factual that shouldn't be ignored.
  7. Occam

    Broken images

    Exactly, hence my question marks! No offense, but ... this is just wag the dog! The Niara theme is not so important, that you have to introduce own functions. It would be much easier if this theme just meets conventions. Period! And new creations like Niara_smaller and Niara_smallest are not covered either by other modules, because they are simply incompatible. Not to mention the fact that the Niara theme itself does not use underscores in image names.
  8. Occam

    Broken images

    ????
  9. Occam

    Broken images

    I'm afraid you missed the point. This is not about fixing bugs, this is about maintaining compatibility.
  10. Occam

    Broken images

    50 minutes ago, Traumflug said: It simply shouldn't matter which image type names a theme uses. There's a database table storing these image types and the whole point of this table is to allow changing these names. A theme can define any image type name it feels a need for. This was "always" the case. 1. I'm afraid, I wouldn't agree, Markus. This would be ok if there weren't third party modules that use standard naming convention and don't consult any database entries. 50 minutes ago, Traumflug said: And then there are modules entirely ignoring all this and hardcoding image names, as if there was always just one shop, just one theme and this theme always had defined image types the module wants. A static world view, just like 1990. For a start-up like thirty bees a statement like that sounds pretty presumptuous. Shouldn't thirty bees remain compatible for now? 2. Thirty bees 1.1.0 stores different names depending on the fact if you use only one or several languages. Example = 1 language: Niara_home Example > 1 language: en-default-Niara_home, de-default-Niara_home, es-default-Niara_home etc. The latter will be found, the first not, as you may read form this exemplary code from product.tpl: src="{$img_prod_dir|escape:'html':'UTF-8'}{$lang_iso|escape:'html':'UTF-8'}-default-large.jpg" srcset="{$img_prod_dir|escape:'html':'UTF-8'}{$lang_iso|escape:'html':'UTF-8'}-default-large.jpg" Not to mention the fact that the theme installer doesn't configure a default_large master file for Niara. There's something fishy about it
  11. Occam

    manufacturer Advice

    If $show_brand_logo is boolean which I assume, it can only be 0 (deactivated) or 1 (activated). So if $show_brand_logo > 1 makes no sense and must therefor cause an error.
  12. Occam

    Broken images

    This already has a tiny disadvantage: the Niara theme won't find the images afterwards, because in the theme as well as in many modules the picture format names are hard coded - no matter what @zen believes.
  13. Occam

    Broken images

    Though I'm not sure if compatibility with PrestaShop is a chief aim of thirty bees anyway, I'm puzzled too. But in this case not by any lack of compatibility, because my current test professional (thirty bees 1.1.0) creates the expected defaults, though not really following the naming convention (default is not attached but prefixed for some unknown reason): en-default-Niara_home_smaller.jpg, en-default-Niara_large.jpg ... Weird! But at any rate bad practice.
  14. This may be a desirable solution from a programmer's point of view, but most merchants are pure users. They don't have your knowledge and don't want it. They are looking for a ready-made and want to sell. We already experienced this in Prestashop when Francois-Marie had the idea of the Starter Theme. That absorbed a lot of energy and was discarded at some point. The concept of the child-theme also seems to step in the same direction - but I feel that the needs of the average user are not met with such features.
  15. I know this format which unfortunately does not comply with some of the bigger European countries though throughout the EU there is no common standard. For instance UK is more likely between the US postal format, but not the same.
×
×
  • Create New...