Jump to content
thirty bees forum

dynambee

Members
  • Posts

    837
  • Joined

  • Last visited

  • Days Won

    5

Posts posted by dynambee

  1. 26 minutes ago, datakick said:

    This is a forum, one of many forums I'm participating in. I'm subscribed to hundreds of threads. Unfortunately, it's very easy to miss/forget some message.

    Fair enough. I've removed that message.

    It was just frustrating to take the time to write up a detailed report with specific examples and screenshots, and then ... nothing.

  2. 5 minutes ago, datakick said:

    Not sure if this is a bug, really. It's definitely nuisance / ui glitch, but I don't think it prevents anyone from completing the checkout flow. 

    It's on my list of todo tasks. Very low priority, tough. 

    Thank you for at least replying and letting me know.

    In the meantime I have worked out a solution that works around the problem for my particular situation.

    Thanks for all the work you do on Chex and other modules, I hope to buy more stuff from you in the future.

  3. Bug report / feature request:

    I've noticed an inconsistency in the way that Chex is working with regards to the selection of states in addresses, and I have a request for how to fix this.

    I am running the latest version of Chex, 0.7.0 as of this writing.

     

    The issue:

    At the start of the checkout process in the "shipping and payment method" section when you choose a shipping destination country, if that country has a list of states then a default state will be auto-selected. The default is the first state in the list. Like this:

    spacer.png

     

    When you move further into the checkout process the collapsed "shipping & payment method" section looks like this:

    spacer.png

     

    However, when you get down to the "Personal details" section, the country & state selection looks like this:

    spacer.png

    As you can see above, no default state is auto-selected.

     

    Furthermore, once you select "Australia" (or any other country with a list of states) in the "personal details" section the "shipping and payment method" section changes to show the country instead of the state, like this:

    spacer.png

     

    Requested solution:

    Please do not have a default state selected in the "shipping and payment method" section.

    Alternatively, please allow shop owners to select if they want a default state to be chosen and then have that preference apply in both sections of Chex.

    The reason I request this particular solution is that some shops will require a state to be selected in order to calculate shipping charges while other shops do not require a state to be selected as the cost is the same for all destinations within each country. Allowing shop owners to select this allows for maximum flexibility during the checkout process.

     

    I hope I have explained everything well but if I haven't please let me know and I will be happy to clarify with additional screenshots as needed.

     

     

     

  4. 1 minute ago, AnnaLisik said:

    @dynambee I dont (fully?) agree with loosing things like forums/blog, website, knowledge, partners etc. Why did you say TB would loose it?

    Forking, by definition, means the project is split and there is a new project created. The new project is not TB any longer but some other new project. The only thing the new project gets is the open source code. Code is a lot, but it's only a small part of what TB is in total.

    If @lesley is going to hand the name, forums, blog, website, knowledge, social media, etc etc etc to "the community" or to some new entity then there is no need to fork because obviously in that case the existing repository would be part of that hand over.

    • Like 2
  5. 8 minutes ago, Briljander said:

    I agree that there is a lot of work and effort put into this project that would be better for everyone not to do allover again but in the other hand I don't think the brand is worth a couple of hundred thousands. 

    The valuation on paper is probably more than any of us can afford to pay. Startups with customers & a functional system tend to be valued quite high -- again, on paper.

    The actual valuation is what someone is willing to pay. Sometimes there are very big differences between the two. Sometimes the first is very high and the second is zero. Other times companies way overpay for acquisitions if the target is for some specific reason worth more to THEM.

    With TB it probably depends on what @lesley wants to see happen to the project and if he see himself being able to come back and take the lead again sometime soon.

  6. 1 minute ago, AnnaLisik said:

    Now I get it :: in your concept fork = start over. But no. By fork, I understand taking the code as-is, just changing the owner of repo and push/pull paths. Thats it! No need for redoing anything. Just change owner, than change push/pull paths locally and off we go - the project is ready to accept contributions. As simple as this.


    You really don't seem to understand.
     

    If we fork we GET this:

    • ThirtyBees code
    • ThirtyBees' modules' code

     

    If we fork we LOSE this:

    • ThirtyBees name
    • ThirtyBees website & SEO
    • ThirtyBees branding & design
    • ThirtyBees forum (including all users and multiple years of existing knowledge & content)
    • ThirtyBees blog (including all knowledge, posts, and discussion there)
    • ThirtyBees social media accounts
    • ThirtyBees supporters platform & all existing supporters
    • ThirtyBees modules & themes store (which I think was a custom build on top of a TB website)
    • ThirtyBees existing installed user base -- there is no guarantee that any of them would move to a new & known to them platform
    • ThirtyBees partners, of which there are quite a few and that took a LONG TIME for ThirtyBees to build up.
    • Probably a whole lot more that I am forgetting to include here

    All of that would be GONE and need to be REBUILT FROM NOTHING. It's a massive undertaking.

    Also, while a fork would give us the code, it would still need modification. Currently all error messages and branding show the ThirtyBees name. This would all need to be fixed. It's not a simple "search and replace" either as there are many copyright notices in the existing code that would need to be maintained. Forking doesn't invalidate the TB copyright for existing work. The included themes (community & naria (sp?)) would need to be modified and changed to the new branding, too.

    So while forking does give the code it gives NOTHING ELSE. I can understand that to many programmers the code is "everything" but I promise you there is much, much more to a successful project than just having the code.

    • Like 3
  7. 9 minutes ago, AnnaLisik said:

    In this case the only (?) thing that would change is the owner, right?

    Correct.
     

    9 minutes ago, AnnaLisik said:
    47 minutes ago, dynambee said:

    Forking would be a last resort, IMO.

    why?

    I'm sorry, but did you read my previous post at all? There is a huge amount of work that would need to be redone from scratch if the project is forked. Website, SEO, blog (all existing posts & knowledge gone), forums (all existing knowledge, discussions, & users lost), social media, module shop, existing supporters platform, etc. If it is absolutely necessary to redo all that work then fine, it has to be redone. I'm curious though, are you volunteering to pay someone to do it? I expect it will be quite expensive to duplicate the level of branding & design that already exists, and yes, branding and design are important if one wants to be taken seriously as a business, project, & platform.

    Personally I don't think it is a good idea to reinvent the wheel unless there is no way forward that can save all the existing work.

    Edit: I'll also add, a fork would mean needing to redo the existing core themes and edit the codebase to change everywhere the TB name appears to be the new name. This may sound trivial but it took ages for TB to get that right. I think even now there are times that PS pops up where TB should be instead. It's just more work that needs to be redone, duplicated effort. Starting with a completely existing platform means all effort can be spent on pushing the project forward. Forking means a huge amount of effort has to be wasted to redo work that has already been done once.

    • Like 1
  8. Forking would be a last resort, IMO.

    It is time consuming and expensive to establish a new brand and rebuild everything from the bottom up. It would be better to keep the existing brand, website, forums, repos, module shop, supporter payment system, (and more) in place.

    If there is absolutely no way to work things out and keep the existing structure then a fork and rebuilding can be considered, but it's an immense undertaking.

    • Like 1
  9. So to be clear the $50/month isn't specifically a license but more like a membership that lets you have some input into the direction the project takes, correct? I assume the money would be used to pay for development? Who would manage the money?

    Assuming things are set up well I'd be willing to contribute $50 a month.

    • Like 1
  10. I'm not sure of your situation, I can only tell you about mine. I have three standard options:

    1. Slow, but very cheap. No tracking, no insurance.
       
    2. A little faster, has tracking, basic insurance. Middle price.
       
    3. A lot faster, better tracking, more secure, can be insured up to $20k. Highest price.
       

    If someone buys a $2 item I don't care which shipping they choose. There is no need to stop them from choosing better shipping if that is what they want, if they are willing to pay for it.

    If someone buys a total cart value of $50 I don't care if they choose option #2 or #3 but I don't want them to have #1 as an option. Again, if they want to pay for faster shipping then #3 should be available to them.

    If someone buys a total cart value of $200 then I only want them to be able to choose #3.

    This is why I don't need a minimum price.

  11. On 4/13/2020 at 8:39 PM, datakick said:

    I just wanted to say good bye to all of you. I decided that I will no longer participate on thirtybees project development, as it takes too much time and effort on my part. Lately I was feeling like I was the only one pushing this project forward. And I'm not even affiliated with the tb company, I was just a volunteer doing this for free.  

    Thank you for your tremendous contributions. I wish there was a way you could stay, perhaps at a reduced level of contribution, but I understand time is valuable and very limited.

    I hope to see more cool TB modules from you that I can spend some money on. 🙂

  12. 9 minutes ago, toplakd said:

    Above mentioned options from @dynambee sound good, but missing the option to enable minimum price - to not show more carriers than needed.

    It shouldn't be difficult to implement a minimum price feature, I just don't have a need for it myself. I only have 3 or 4 available carriers to any given destination and they are all clearly separated by price & delivery speed. I just need a way to make sure someone making a big purchase can't choose untracked & uninsured shipping.

  13. 35 minutes ago, lesley said:

    Personally I would say no to this. I know I have been away and my opinion might not be valued as much any more

    Hi @lesley, I'm sorry to hear you have been sick, and I hope things are improving for you.

     

    36 minutes ago, lesley said:

    there would be problems trying this in a wide release. The main issue would be overlapping ranges, it would be hard to hedge against and give proper warnings.

    I agree, making fundamental changes to the way a core feature like shipping works is likely to break a lot of stuff in unintended and unexpected ways.

     

    37 minutes ago, lesley said:

    It could be done, but if you are using a table rate like this you do not depend on accurate data. What I mean is when you have a weight entered, but you are not passing that rate to an api, its just used in house. So it does not need to be that accurate. It can be totally wrong for all intents and purposes. You can just hedge the weight to and manipulate it to make carriers work how you want.

    In some cases this can work, but it's not a total solution. If I understand correctly you are suggesting to use different weight ranges for different types/prices of items. For example, for cheap items use their real weights. For expensive items, add 1000lbs or 1000kgs to their weights and then make separate shipping carriers with shipping costs set for those high weights instead of the real weights.

    This can work well if you have clearly delineated items that people don't buy in multiples. For example if you have a $2 item that people only ever buy one of, or maybe 2 or 3 of, your system would work well. However if you have a situation where people sometimes buy 1 or 2 of a $2 product but other times a bulk buyer comes along and buys 100 of them, you still have a problem. You don't want the bulk buyer to be able to use the cheapest types of shipping, often without tracking or insurance. At the same time you don't want the person buying a single $2 item to have to use expensive shipping.

    Of course this can also be worked around by having different listings on the site. $2 single items with 10 in stock, then listings with bundles of 10, 20, 50, 100 etc which would have different shipping carrier options. This kind of works too, but it's not a very elegant solution.

    This is why I had a module created that uses an override to enable a maximum price for carriers. It doesn't screw with the core shipping system but still allows me to limit the total cart value for a given carrier. This gives me total flexibility without making me do unusual things like incorrect weights or bundle listings. It's still not a perfect solution because the errors displayed by TB don't always match the real reason a carrier isn't available but it does work.

  14. 2 minutes ago, toplakd said:

    My working solution allows minimum and maximum price limit setting for the carrier and is working as wanted.

    I'm glad you have a working solution. I don't personally have a need for minimum price setting as it's not a problem for me if someone wants to ship a cheap item with expensive shipping. I've seen it happen where people pay $20 in shipping for a $1 part because they need it immediately. The reverse however is a huge problem, I don't want basic untracked shipping used for shipments over about $30 in total value so I need a maximum value set for basic carriers.

    What I actually ended up doing is creating carriers on a per-country basis (we ship everything internationally). This allows me to set different limits for different countries, or to completely exclude some types of shipping to some destinations. It means I have a couple hundred different carriers defined but they were created programatically so it's not an issue.

  15. On 3/29/2020 at 5:50 AM, haylau said:

    @dynambee had a module developed that helps with this. He was considering releasing but not sure if he did. Not quite the same, but it allows you to set a cart value over which the carrier is not available

    I wanted to list it and a couple of other small but useful modules in the TB store for a nominal price, say $10.

    Unfortunately the cost to list in the TB store is very high which makes it not financially viable for me to do so. I'd much sooner have a situation where I don't pay a yearly fee of hundreds of dollars but instead TB takes, for example, a 30% cut of the sales.

    Not my decision to make of course, I can only say that I can't personally afford the high cost of entry.

    Edit: And yes, the module I have does fix @toplakd's problem. Carriers are set up as usual with weight ranges. Then separately you set a maximum cart value for a carrier. If the cart value exceeds that amount the carrier is no longer available to the customer. The only caveat is that this module does NOT work for custom carriers added via separate modules. It only works for carriers you define using the standard TB shipping system.

  16. 38 minutes ago, Theo said:

    Perhaps you're right. However, I couldn't find the entry in question ('page') using phpMyAdmin (it's not in tb_meta).
    So before I just added a new entry to the table, I refreshed - and all was good. Or so it seemed.
    So should I add an entry to tb_meta table for 'page' or is it in another table somewhere? 

    It's not an entry in the table, it's the table column named `page`. If you run this command on an SQL server:

    SHOW CREATE TABLE tb_meta;

    You will see something very similar to this:

    CREATE TABLE `tb_meta` (
      `id_meta` int(11) unsigned NOT NULL AUTO_INCREMENT,
      `page` varchar(64) COLLATE utf8mb4_unicode_ci NOT NULL,
      `configurable` tinyint(1) unsigned NOT NULL DEFAULT 1,
      PRIMARY KEY (`id_meta`),
      UNIQUE KEY `page` (`page`)
    ) ENGINE=InnoDB AUTO_INCREMENT=86 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci

    As you can see, the `page` column is there and is a varchar(64) which means it can hold up to 64 characters per entry. The command provided by @datakick changes that from a varchar(64) to a varchar(128) so that it can hold up to 128 characters per entry.

  17. 1 hour ago, Theo said:

    Bytw: in my case (also a Panda issue), I did not have to implement the MySQL update. Just thought I'd let you know.
    Just implemented the changes to Meta.php and problem went away. Thank you

    This is potentially a bad idea. You should check the data table in question because what you are probably going to find is truncated data. Depending on how MySQL is configured it will silently truncate strings that are too long. Trying to insert 500 characters into a VARCHAR(255)? It might just insert the first 255 characters and not give any error. This causes weird problems down the road when you try to retrieve that data and you only get part of what you expect to get.

  18. 2 hours ago, Briljander said:

    Did 10.4 work for you?

    Yeah, MariaDB 10.4.8 is running without any troubles or apparent compatibility issues.

    It's a CentOS7 server (not that it should matter, really) running CWP and I did the upgrade manually following the steps shown here. CWP seems just fine with 10.4.8 as well.

    On the Thirty Bees side of things, I am running 1.1.x Bleeding Edge.

×
×
  • Create New...