dynambee

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.

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.

[removed]

Did anything ever come of this discussion? Is @lesley okay? What is the status of TB?

@Havouza, it is fantastic to see you back in the forums. I hope you're well.

@datakick, I realize you're a busy guy but could you at least comment on my bug report and feature request?

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: When you move further into the checkout process the collapsed "shipping & payment method" section looks like this: However, when you get down to the "Personal details" section, the country & state selection looks like this: 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: 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.

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.

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.

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.

Correct. 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.

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.

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.

Trying to modify the core like that will lead to unexpected consequences for some users. You should implement this as a module.

I'm not sure of your situation, I can only tell you about mine. I have three standard options: Slow, but very cheap. No tracking, no insurance. A little faster, has tracking, basic insurance. Middle price. 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.

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. 🙂

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.

Hi @lesley, I'm sorry to hear you have been sick, and I hope things are improving for you. 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. 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.

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.

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.

I’m wondering if this module has been abandoned?

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.

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.

It's like asking someone to fix your car but refusing to let them look under the hood. Either give people the access they need to help you or figure it out on your own. The choice is yours to make.

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.