dynambee

That's a good question. I last updated modules a week or so ago so there is a good chance that there was a newer version of Core Updater available. It would seem that prior to allowing updates to be done Core Updater should check to make sure itself is the latest version. If it is not the latest version users should be told to first update Core Updater from the modules page.

I already nuked my dev site so I can do a fresh install, but I had the core updater set to update the themes (not to ignore the themes) and it wasn't updated or installed. It did not appear in the back office under Preferences -> Themes. Only the original Community Theme was there.

As the theme is not available on the TB store yet how does one install the new theme on an upgraded site?

A huge thank you to everyone who worked on this!

My idea was that coins would slowly expire over time if they aren't used. This seems kinder than losing all coins at once if a customer doesn't make any purchases for X days. If a customer does use coins then the coins they use would be removed from their oldest coins first, going forward. So if they had 200 coins from 3 months ago and 300 coins from last week, the coins they used would be removed from the older 200 coin balance first. If they use more than 200 coins then the extra coins would be removed from the newer 300 coin balance. I guess it depends on how the module handles coins. In my experience some customers like to save up coins until they have a lot of them and then use the coins to make a "free" purchase. Some customers might save coins for years and then use them all at once to buy something expensive. In my example situation from above coins would slowly expire over time so that customers couldn't do this saving process. Basically I sell expensive items and have some regular customers. I like the idea of loyalty points but I don't really want a situation where a customer has $1000 worth of coins and uses them all at once. I don't want to have to carry that unrealized loss for years on the accounting books and I don't want to have to suddenly cover a large quantity of coins all at once. Also, a quick question about how the coin amounts are calculated: Let's say I give 5% coins for purchases. Customer has 1000 coins ($10) saved in their account. Customer makes a $50 purchase and uses all 1000 coins. This means the customer pays $40 by credit card and $10 by coins. How many coins do they get for this order? 5% of $50, 250 coins or 5% of $40, 200 coins?

I really appreciate that you made this module and released it to the community and I do not wish to come across as ungrateful in any way. Thank you for your time and hard work. I just think that allowing unlimited points to accrue with no expiration could end up being a problem for a merchant. Not immediately of course but 2, 3, 5 years down the road. Enabling point expiration allows merchants to mitigate this risk while also encouraging customers to return and use their points before they expire. As an aside, AFAIK accrued loyalty points should be recorded in the accounting books as an unrealized loss. I'm not sure if the module shows the total outstanding point value or not but having a way to do this would be helpful.

When I visit your linked page now that checkbox is checked when the page loads.

Perhaps the way things expire could be user selectable? In my case I would like loyalty points to expire if not used after X days (180 days, 365 days, etc). I don't want user orders to reset this counter because what I want to avoid is accruing a large liability of unused points. I guess this would mean changing the way points are stored in the db to match what @datakick described in this post. Storing points on a per-order basis would also make it easier to know how many points to remove if a customer returns a purchased item. While it would mean rewriting part of the module it seems like it would be a more flexible overall solution.

Yes, I think the existing module is only for uploading new products. Adding the ability to update at least stock & price by CSV would be a huge plus for the platform, IMO. I may look into creating a low-cost module that allows CSV updates of stock & price. Personally I currently accomplish bulk stock & price updates by sending a bulk update file over SSH and then importing it directly into MySQL from the command line.

Your shop is in maintenance mode. None of us can see any of your links.

This is a bit of an old post now but I'm replying to it as there doesn't seem to be an answer and it's likely that other users (especially new users and potential users) will be interested in knowing more about this. For importing new products into your store Thirty Bees has an excellent CSV import system built in. You can find it in the TB back office under Advanced Parameters -> CSV Import. I'm not sure if the existing system supports updates but I suspect not. Perhaps @lesley or @Traumflug could confirm? Enabling bulk updates via CSV seems like it would be an in-demand feature if it doesn't exist already. Even if it was only for updating stock & prices it would be great.

Quick related question: If one imports a quantity of products via a CSV file how are photos added to the products?

I suspect you might get more help if you gave a little more information about your hosting situation. Which host, what version of PHP, which webserver(s), etc.

Thank you for this, it's really helpful. Do you think running nginx + php-fpm will be noticeably faster than using the more traditional nginx + apache + php-fpm? Are there any downsides to using just nginx + php-fpm?

I'm really sorry to hear this happened to you. PayPal can be very arbitrary sometimes and it's really hard to see how they come to some conclusions. You could try reaching out to them on social media (Twitter in particular) if you don't make any progress through their customer support. You might want to proactively reach out to Stripe and let them know your expected sales volumes and talk to them about your business. You're doing enough sales volume that you are likely to pop up on their radar as a new customer and being proactive about it will be better than reactive.

Aren’t both Warehouse and Panda developed by the same person?

I can't find the data I read about it, though I have just been trying. The website you linked to seems to say that UNIX is still by far the dominant platform (nearly 2:1) for hosting, which I guess means BSD. Are there really that many web servers running on BSD these days?

Yes, it's on the page where you can edit your own signature: https://forum.thirtybees.com/settings/signature/

It's in my sig. 😉 I've been here in Osaka for about 25 years.

PCI Compliance is a giant pain in the ass at the best of times. I do not expect to deal with card data directly and will use PayPal & Stripe to process all payments. Maybe at some future time it will be an issue for me but not right now. (Card processing rates for small businesses in Japan are absurd so using PayPal & Stripe really won't cost me much if anything.)

That got me curious and actually cPanel and CWP have the same distro support: CentOS, RHEL, and CloudLinux. I guess that's one of the reasons CentOS is the most popular distro for web servers.

I like CentOS so that’s an upside for me.

After some more monkeying around I have worked out what seems to be the best way to do this. This is probably super obvious for anyone with more Apache configuration experience than I have (which is almost none) but the best solution is to add a vhost configuration file for the domain in question. With CWP these files are stored here: /usr/local/apache/conf/userdata/[username]/[domain] So if your username is 'myaccount' and the domain is 'example.com' it would look like this: /usr/local/apache/conf/userdata/myaccount/example.com You can call the file whatever you want as long as the extension is .conf. So let's call it thirtybees.conf: /usr/local/apache/conf/userdata/myaccount/example.com/thirtybees.conf The contents of the file: <Directory "/home/[username]/public_html"> Order allow,deny Allow from all Require all granted </Directory> Obviously replace [username] with your account's username. After the file is saved in the right place then restart Apache. The webservice (api) will now work.

Here are the prices prior to the increase, compliments of the Internet Archive's WayBack Machine The lowest level of the new accounts actually doesn't seem like a bad deal since it offers 5 accounts now when it only offered 1 before. Still, for anyone that only needs 1 account that's an extra $5/month for nothing. The mid tier goes up by $10/month and now limits users to 30 accounts. The top tier stays the same price but now maxes out at 100 accounts unless you pay extra for more. They've also removed the yearly discounts which were a substantial savings before. This definitely reaffirms my decision to go with a free panel (CWP). The cheapest version of cPanel now costs as much as I pay for my entire VULTR VPS and VULTR isn't even a particularly cheap VPS provider!

It seems that the solution I posted above (changes to the vhost settings) is a good overall solution for my situation and does not weaken external site security. There is a potential issue where Options FollowSymLinks can make it easier for an attacker who has access to one site to attack other sites on the same server. For me this isn't a problem because a) all the sites will be mine, and b) all the sites will be running TB. If an attacker finds a hole in one TB install the same hole is going to exist in all of them. The attacker will *already* have access to all the sites without having to try to exploit a cross-site attack. So for now I'm happy. All the API automation code I have in place is working and I am adding & testing more each day. Looking forward to getting my first 4 or 5 sites up and running soon. 🙂