Traumflug

Thanks for the warm welcome, folks. In Germany it's a habit to bring along some gift on entry, so I did that. In form of bug fixes, of course: https://github.com/thirtybees/thirtybees/commit/677c014a38b5ec9cd175c3a95a5ac5591bdfc7c5 https://github.com/thirtybees/thirtybees/commit/358b22f43d92d96c7b7e7c7fbaaedf7695bc36c9 https://github.com/thirtybees/thirtybees/commit/6ee2507fc30458065f3d98550fd9ec6c52a0416a (they make thirty bees fit for a pure Nginx server)

Sounds like a pretty worthy enhancement, doesn't it? I think many shops use such "packs on the fly".

TB is in 2nd place behind Wordpress, now. Wordpress was apparently removed from the list. Good choice, because e-commerce with Wordpress is actually WooCommerce.

The problem is actually making a release. Any release, 1.0.3.1 or 1.0.4 or whatever. Making a release should be a matter of running a script, but actually it's a lot of handcrafting, where some parts are more guessing than applying well known procedures. On top of this, the updater module is bit-rotten enough to make a rewrite easier than fixing it. thirty bees is currently collecting a list of required features and evaluating proofs of concepts for an entire new updating mechanism. New packaging scripts, new updater module. A solid solution is needed and it's worked on.

Guessing a bit, for moving a shop into a subdirectory one uses the Base URL, not Virtual URL Let's assume your web server serves stuff at /var/www/. Then you install the test shop in /var/www/testshop/. This makes Base URL testshop/ and the shop is available at http://localhost/testshop/. A Virtual URL is needed if you want to access the same shop at http://localhost/testshop/clothes/. It's a bit complicated. There are quite a number of possible combinations of installation location and access URL and thirty bees implements all of them.

Ideally It should show me login screen right away when I click back button on browser . That's what my browser (Firefox 59.0) does. Apparently you have some caching mechanism in place which keeps the previous page. Thirty bees is placed on the server, so it can't do much about how your browser behaves.

@Twincarb An example of what I am wanting to achieve is: a garment that has a fixed price including VAT, also has an option for extra wording (name/nickname). This is where a text box would come in for the customer to enter the extra text required. When this box is filled in it would add an extra cost to the item. I see, this makes sense. To get an extra text field, go to Back office -> Catalog -> Products -> (select product) -> Customization. There you can get as many text fields as you like. Also file fields, where your customers can upload a file, e.g. a picture to be printed onto a t-shirt. To get a specific price, "Combination" is the keyword. Can be set on the same product page. If I understand correctly, you'd want to have a combination with "no text" and "with text". Having such a combination you can go to the product's prices area and add a "Specific Price". For example $15.- more for the combination with text than the one without. That's all a bit complicated to set up, but it should work out of the box. Looking at the demo products can help, e.g. the tin cup has a combination to feature two different colors.

How about handling VAT properly instead of a text field kludge? First thing is, increasing the price under certain conditions is illegal in many countries. Even where it's legal, customers might develop a tendency to simply not enter these magic words. Better show the higher price, then lower that under the opposite set of conditions. If this price distinction is actually VAT, one can handle it even better. Thirty bees features customer groups and the usual way is to create a group which is allowed to see and order for prices without that tax. Customers qualifying for VAT-less prices then log in to identify them selfs.

Done.

@rand0m Also I think that there might be people who could contribute codewise but just aren’t accustomed to github Github's issue tracker is pretty easy to use, so it's fine to discuss things there. Github's enforced pull request strategy is indeed [censored]. To get patches into discussions, don't hesitate to send diffs/patches to my email, I'll happily apply them. Unless the enhancement is obvious I'll apply them in a branch, first, then cherry-pick them to the development branch if found to be good.

Having that many resource loads is a result of the software not being monolithic, but coming with modules. Pretty much every module comes with its own JavaScript and with its own CSS, so each has to be loaded. Not sure whether CCC helps, didn't try. To find out one has to measure page load times. It's well possible that compressing resources takes longer than sending them uncompressed.

@zimmer-media The last comment from traumflug [...] is again an example in which my neck bursts. This way he responds -> is a great ad for the image of tb and then just so violent a reaction. This is simply telling the truth. If the truth is violent to you, then sorry for your neck. Now my personal opinion: if I can't stand something in open source communities, and I participate in quite a number of them, then it's all those whiners and lamenters. "I'm a newbie", "I can't", "I have no time", whatever. That's nonsense. Everybody had to start as a newbie. Everybody had to learn. If one has no time for working on a solution, one has no time for writing forum posts either. Volunteers become heros, because they don't lament, but sit down, take the time and start working on a solution. You'll never see me turning down somebody trying, but not (yet) succeeding. They'll receive the best support I can give. On mailing lists where professionals have a majority (e.g. FreeBSD, Git), I rarely see lamenting. To receive acceptance there one has has to show up with code, with a solution or at least with an in-depth analysis. Are we among professionals in this forum? I hope so.

@mockob said in Forcing customer to choose an attribute: NEVER said anything to hurt his feelings. Here you did: it is still a hack. I already contacted developer to make me custom solution about this, that’s if I ever run tb shop. And it will be paid service if that’s your or any other’s concern. Calling a gift to be bad and turning it down in favor of something costly is about the shabbiest one can do with such a gift. Still no big problem. Next week you'll hire that developer, spend $1500 for a "proper" solution and donate the result to thirty bees, right? After turning down wakabayashi in public you have to stand to your word.

@mockob said in I will say goodbye: I don't get it why some of the users here think that @zimmer-media has to pay for solving native bugs. Simple answer: because thirty bees is open source. When choosing a paid solution one pays bug fixes with the purchase price / subscription fee. When choosing open source one has to fix bugs oneselfs or pay for fixes one way or another.

@zimmer-media said: With this unwanted extent in this topic of a real farewell, there was hopefully more food for thought to make more of it -> positive development. To reconsider some things. The clouds over TB were apparently darkened in the last few days. The community has been waiting for weeks for many answers. And I'm the dumbass now. When starting a discussion along the lines of "I'm leaving, it's stupid here" one can't exactly expect to receive cheering.

@mediacom87 said in I will say goodbye: TB should not make the same mistakes as PS by adding features on micro release. True. Even if it's sometimes tempting to add a feature, which also fixes a bug, which is already written. That said, I'm pretty positive thirty bees should actually start reducing features and configuration options. Each feature and each option adds chances for bugs and reduces maintainability. KISS rulez :-) But guess how popular that'd be in a community which mostly exists for asking for options even for the most distant corner cases :-)

@zimmer-media said in I will say goodbye: sorry to read this and must smile - i think it isnt paid, you can download free from github **ouch* Some code being open source certainly doesn't indicate the work for writing this code isn't paid. Yes, there are people out there who pay others for writing open source code. Actually, most open source code is written by developers paid in some way or another. Reason for this is simple: coding has to be paid anyways and making code open source makes it more reliable.

@nickon said in Is thirty bees dead?: And the money? Most open source projects do not make money from selling products. They make money from support and customization. Not too sure on this one. People see their "almost ready" shop for free or a small hosting fee, so they struggle quite a bit to spent like $5000 to get these last 10% of work done. They see a free module close to their needs, so they struggle to spend like $2000 to get one precisely to their needs. And no, there are no $50 "quick fixes" for custom work, such contracts are usually promotional gifts. In general, many small income sources are more rewarding. Do the work once, sell it 1000 times. Like with, well, a paid module. Or for thirty bees, with a share on modules sold by other developers.

Sieht auch so aus, als ob das Modul prinzipiell vorhanden ist, nur der Text fehlt. Es könnte also ein Problem mit der Übersetzung sein. Wenn die einen leeren String liefert, gibt's natürlich keinen Text. So oder so wäre ein Blick auf das HTML dieses leeren Kastens eine gute Idee. Und ein Versuch mit Englisch, das auch ohne Übersetzung funktioniert.

If installation is the easy part, go ahead and do it. Then get it in alignment with your local laws, which is the hard part. Then put it online. Installation of modules and themes can always be done later. Unless you're in a highly competitive market (e.g. clothes), having a super fancy design isn't that important. Making your store known to the public is. As always, running the shop gives experience. Becoming known takes time (and marketing efforts). That's why I consider being online as early as possible to be more important than solving detail design questions.

Fact is I could reproduce the error now That's good! Please open a Github issue with the list of steps to reproduce the issue. Maybe it sounds a bit snobbish to some merchants, but the way to go is still to identify issues one by one and to create a list of steps to reproduce the issue for each. Reports like "I've seen this a while ago" or "there's something wrong" don't help. The only way to get an issue solved is to help developers to reproduce it on their development installation. "Click here", "Type that", "look at this page". Like teaching it to a child. Like magicians, developers might be in an entirely distinct environment, so they have to to configure their development shop to match yours. Other than magicians, developers can only fix what they see. Which means: if you see an issue, make a screenshot. This way developers can see what's going on on your site. If you've found a way to make it going away, please report this in words as clearly as possible. If you know a way to reproduce it with a fresh installation step by step, you're golden :-) And all this into a Github issue, please, one Github issue per issue found.

It should certainly be possible to have products with spaces in their name. Actually, a number of the demo products have such a space. Could you make a screenshot? Is quantity above zero?

Without checking this: Reference is an arbitrary string, isn't it? Often seen like demo_1, demo_2, etc. It's just a coincidence that this string happens to be a number in your case. Product IDs are pretty much unchangeable. One can change them in the database, of course, but this would break relationships to pretty much all other tables. If you insist on a particular ID, delete the product and re-create it via CSV import. Regular product creation doesn't even allow to set a particular ID.

@SLiCK_303 as it's about a bug, moved this to the bug reports section.

Seen this, too. Because there's no error text it's hard to find the code causing it.