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.


  • Content Count

  • Joined

  • Last visited

  • Days Won


wakabayashi last won the day on June 11

wakabayashi had the most liked content!

Community Reputation

514 Excellent


About wakabayashi

  • Rank

Recent Profile Visitors

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

  1. @veganline In such a case we normally send a postal return code to the customer. If this is not possible in your case, i would ask for bank details and refund like. If the customer orders in future, you could also make a voucher instead 🙂
  2. wakabayashi


    I would guess a JS error. Check your browser console...
  3. Thanks for the explanation. I didn't consider that. This makes some sense. But still not completly IMO. Wouldn't it be then logical if this field is set, when you add a special price? Cause your argument is probably also valid, if you wan't to only make a sale for a certain customer group. But I am sure, we both agree, that this point is by far not the most important/intersting on my list ☺️ I understand, if my list is a bit overhelming, but maybe somebody has some concrete stuff to criticize or to vote up some points.
  4. I know that 😊 I more meant: why do I have to set it as a merchant? If I set a special price, do I ever want, to not display this label? :S
  5. @Quant I am sorry, but I don't understand some things, you said. And with many others I disagree. I would agree, that modules are a great way to expand shop functionality. But I hate the mantra: IMO this exactly the reason, why we cant sort product lists for average review rating or why we cant have a clean filter on product lists. It's also the reason why you dont have a clean sitemap for google. Of course often you also could build a clever module that is extendable. This would be true for a sitemap module for example. But how many extendable modules with hooks do you know? And how many of this hooks are used by other modules? Again you do it. Then you also agree, to add no image link at all to the $products array? IMO in a clean world, the theme would state, if it has a hover functionality. If yes, a function like Product::getProductProperties would add e second image link. It would simplify things so much for every theme desinger. In general I have the feeling that a lot of Devs and some merchants only see the advantages of modules and not the drawbacks. Right now every module with mail functionality sends different template to customers. What does a customer care, if it's a core email or a from a module? He doesn't, he is just confused why he gets different looking emails from the same store. So thats why, I proposed the new Email Hook functionaility. It's not logical to me, that you don't even want that @Quant. Cause it would help the module approach a lot. The checkout is probably not the best cornerpart to start with. It's actually very important, but it's so complex and needs/wishes are so different. Some merchants don't want customer accounts at all. I do even force all my customer to register. And probably most are somewhere in between and offer both options.
  6. It's long ago. I have been here. I have a lot of ToDos on my list. I have taken the most relevant out and post it here: E-Mail: Core function with core template, that just allows to put in some array with content. That way you need just one html file. Each email looks the same and modules can easily add email functionality. Images: Add a cover_2 image to getProducts function In general it sucks, the way one has to get Cover Image as a coder Customers: A way to merge two customer accounts Login as customer (there are modules, but it would be a nice core feature) -> also if there would be an easy way to use it for devs. Imagine you can send email links with default login… Addresses: Clear way to define required fields Sometimes a line more, would help a lot Combinations Allow them for bundles and probably digital products Allow different descriptions for different combinations Allow different gtin for different combinations No forcement of using default combination Products Add archive column -> merchants often don't want to delete product information, but they often have products, that they don't need for ever or at least a big time span. If you have multiple thousands products, it helps a lot for filtering. Same could be helpful for Suppliers. Remove Tags and only use Features Remove on_sale checkbox -> what is it good for? Automate this by checking special prices… Accesoirces groups -> Imagine you sell Digital Cameras. You might want to define USB Cables as accessoires. But I don't think you want to update every camera, always when you got a new USB Cable. Define a default text for available_now and available_later Allow extra fields Product Features: Multiple Features (done) Add Feature types with units or allow at least suffix and prefix value. That way filter modules can work without any issues. A filter module could than easily group values or work with ranges… Create Product Listing Pages from feature values. Imagine you sell books. It would be cool to have a product listing page for "Stephen King" with one click. Categories Allow extra fields or add at least a second description Voucher Allow to use it on product and shipping value. We sell vouchers and customer still need to pay for shipping even if his voucher value is bigger than product+shipping. That's not acceptable. Checkout: A clean checkout with ajax Adress saving Drop the two different checkout system. It's just a mess. Customer Service: Clean forms and handling in the BO. Nowdays you don't even know from where a message comes. Sometimes you get an email sometimes not. Have a good sync with email folder. My wish would be, that I can 100% handle customer cases in BO. Allow shortcodes on predefined messages and include attachments Handling returns Order Status: Remove some functionality and implement clean processes. Imagine you have a Status: "Service in progress". How could you say if the order ist paid or not? This should all be handled by order payments What is logable status good for? In my opinion an order should have two bools: paid and shipped. This should be handled auto by modules. Then you have a status canceled. The rest of status should just be for displaying infos to merchant/customer, no funcionality should be involved imo. Order Edit: Give more flexibility on invoice and delivery_slip generation. Why can't I edit an order after I genereated an order_slip. That makes no sense to me. A merchants knows best, when he needs to change/generate something. In my opion merchants should be able to generate as much invoices as they want per order. I don't see any need for invoice tables at all. I would just save a pdf. Maybe it's naive, please tell me. But I believe for us it would work perfectly. Allow to delete an order state. Sometimes you set it by mistake. Remove "tracking status" What is it good for? Remove "customer more" button. You can just click on the name… We have already too many buttons. Having to buttons to save address "Save as new Address" and "Override". Right now it's always saved as a new adress. In our case we want 90% of the times the "override". Either integrate a usable "return system" or remove it Allow to edit shipping costs (I have actually almost done it) Allow to edit payment method, allow to edit/delete payment lines (right now, you can only remove). On the otherhand the "details" can probably removed. Anybody really wanna save credit cart data on his server? Allow to add a cart rule by code. Order Add: Allow to select the real payment method. In fact you can just select the payment module… Use a real shipping free stuff. In fact it just adds an ugly voucher. Stock: Oh I better don't begin. It doesn't make sense as long as combinations and bundles aren't handled cleanly. Captcha: Simple Usage of Captcha for devs. So that not multiple captcha version are used. Backoffice List Allow better filtering (>=2) Allow better sorting (two columns) Allow custom display of columns -> every merchants wants a bit different columns. Modules: Right now you have to set controllers, where you don't wanna show a module output. In my opinion it would be better if you would set where to show. Why is Payments under modules but Carrier has it own menu in BO? What we don't need: Full Cache Page System -> TB is fast, if you aren't greedy on saving money for a good webspace.
  7. Hey all First of all Happy New Year! 🥳 Yesterday a deal has been achieved and so a new age is starting for TB. I will take this opportunity to step back. As most of you know, I am a merchant like majority here. My business has had a very good year due to Covid, but also due to continuing improving our shop processes. This also lead to some kind of overworking and I have to make some cuts. I felt in the last weeks, that with my way of thinking as a merchant/dev, I am kind of exposed. My ideas, plans and problems aren’t shared by many other merchants. I could come up with dozens of examples (krona, elasticsearch and so on) but the three examples, which hurt me the most, are the following: Carrier order editing. I implemented this feature in our store and it works flawlessly for us. The PR wasn’t accepted for some good reasons, which I planned to fix. But as nobody at all cared about this feature in the community, I haven’t done it. Advanced Stock Management. Stock management is one of the most crucial and complex things, big merchants have to handle. The default version is broken/unusable. Since years! Multiple merchant’s leave the platform because of it. I have invested hundreds of hours to make this to a big strength of our company (chaotic storage, using barcode scanners, creating picking lists and a lot more). But even if I would, I couldn’t share this with the community. It is so far away from the core base and the needs from small merchants. The “50$ VIP Club”. I always believed in the idea, that big merchant’s would have similar pain points like speed, search/filter functionality, order handling, stock handling, customer service and so on. That’s why I thought, it would be clever to unite these big merchant’s. For most of us it would be too expensive to hire a full time dev, who would code this all. So why not collect monthly 3000$, hire a dev and push this project together forward. The payers decide, what will be done, but also the little merchants can use the new stuff for free. It wouldn’t have been a donation at all. Just a strategic investment to share expenses. I know, that I haven’t come up with any concrete offer… I thank the few people, that were open to such an idea, but we were clearly too little and the interest in general is small. I am also a bit shocked, that 50$/month is such a huge expense for many merchants. But most may be really small and at the starting point of their business (ten years ago it would been the same here), others will have difficult economic situation with covid and some just prefer the freeriding. I hoped, that a new fork or owner could bring some perspective back to me. But unfortunately the announcement yesterday didn’t. After all this months of waiting, I was expecting a well written official post with a clear roadmap and plan. That’s why I came to the obvious conclusion, that it’s much easier for me to go ego way. I asked @Smile to delete me as a moderator (which will also be a chance for somebody else, to get more involved in the project). To not give any wrong impressions: I don’t switch the software!! I stay with this codebase, but will cherry pick new commits from thirty bees, prestashop and any thinkable fork in the best way. The rest will be modified/developped internally by myself and maybe I will hire a full dev in 1-2 years. If I am allowed to give you all a last honest advice: don't fool yourself. If you don't have a big budget, this is still one of the best codebase around and probably better than any hastily switch to woocommerce, shopify or whatever... Here and there I will look around and check, what I am all missing 😄 I wish you all good luck! 🙏 PS: Sorry this post was supposed to be short… Regards Emanuel
  8. But you don't have any 50$/month to push this project forward? That really depresses me 😔 That's why I voted for "modified shop". Not meaning this strange software system, but going for own development.
  9. Never heard of it. Their website is very pretty! But it's written in python, so for me it's nothing 😉
  10. Presta 1.6 would make no sense at all. You would go to a worse and even more death shop version ^^
  11. I have never tried it with a barcode, but the normal search is broken in some way. it rarely happens, but sometimes it search the product and shorty after reloads the whole list. Tbh I don't think this to cases are related. In your case this feature is probably just missing. I guess nobody thought on an EAN search like that - even tough it makes sense 🙂 I could imagine that it fails for reference too. But I haven't tested anything...
  12. Well have you opened BO translations? I collapse all fields and use browser search to find the translation...
  13. I would guess OrderOpcController 😏
  14. @Kleijn36 Oh thats sad. Which plattform do you chose? I don't ask, because I want to leave this shop system, but I want to learn, what are the biggest pain points in the system right now.
  15. Thanks for your feedbacks! I want to make clear, that my question has nothing to do with the "new team". I am not part of it... I just wanted to check, if there are enough big merchants, which want to push this project forward. That's why I asked for the 50$/month. Which is ofc too much for small merchants, but for big merchants it would be no problem at all. The idea was to create like a an investor group, that discusses together the pain points and fixes them in a proper way. Unfortunately we only seem to be one or two handful merchants, that need the big improvements (like advanced stock management, order editing or speed improvements). So my hope/idea is probably not realistic.
  • Create New...