Jump to content
thirty bees forum

dynambee

Members
  • Posts

    837
  • Joined

  • Last visited

  • Days Won

    5

Posts posted by dynambee

  1. 4 hours ago, datakick said:

    Did you have latest version of core updater installed?

    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.

  2. 18 minutes ago, Traumflug said:

    Unless one sets Core Updater to ignore community themes, doing an update should install all the files for the new theme. Then one can switch to it in back office -> Preferences -> Themes.

    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.

  3. 1 hour ago, wakabayashi said:

    Yeah I got this. That's why I want to implement the expiration feature. But I really don't get the point having part "expiration". Either it makes no difference at all (when customer doesn't order anymore and lose all it's coins). Or the user loses a part of his coins (in your way) and none coins (in my way). But I as a customer would be totally angry if your case comes in. If I place a new order at your store and still lose some of my coins I would think: Ar they kidding me? I am still buying stuff there, but still delete my coins :S

    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.

     

    1 hour ago, wakabayashi said:

     In addition: how likely is this case? As far as I understand a loyalty points system almost always works like this: You order something and collect a few points. You use them on your next order and the thing is done. Doesn't 99% of the orders work like this?

    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?

  4. 11 minutes ago, wakabayashi said:

    Tbh: that would be quite a huge rewrite/extension. And I really don't believe it's user friendly. 

    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.

  5. On 6/7/2019 at 6:37 PM, wakabayashi said:

    That was also my intention. This makes much more sense to me and is also clear to the customer. I mean a message like: If you don't place an order in your next 7 days, you will lose 10 of your 95 coins is just silly, isn't it?

    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.

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

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

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

  9. 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?

  10. 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.)

  11. 1 hour ago, lesley said:

    The downside is you have to use CentOS. 

    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.

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

  13. 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!

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

    • Like 1
  15. I didn't have problems accessing the webservice, it managed GET requests perfectly, so the webservice itself was fine.

    The issue was that Apache was configured in such a way as to block PUT requests, or at least the type of PUT request needed for the webservice. This isn't necessarily a bad thing as the vast majority of people don't use APIs and don't need this sort of access. In any case this meant I could retrieve data from the webservice but not make any changes. I couldn't enable/disable carriers/countries/zones/etc or send any delete requests.

    After making the changes I listed to the vhost file for my domain I can fully work with the webservice, exactly as I could on Cloudways. I'm still waiting for confirmation from the CWP support guys but for my particular situation I don't think I my changes have affected server security in any meaningful way. (It could make a cross-site attack easier in some situations but since all the sites on the server will be mine I am not concerned about this.)

×
×
  • Create New...